Authorization header. meetergo has two credential types. They use the same header, but they represent different principals. The important question is not which data a credential can touch, but who the API treats you as.
The two credentials
Personal Access Token
Platform API Key
Personal Access Token
A Personal Access Token (PAT) authenticates as the user who created it and inherits that user’s permissions. It is not limited to the owner’s own data; what a PAT can do is exactly what its owner can do:- A regular member’s PAT manages that member’s meeting types, availability, and bookings.
- An admin’s PAT can read and manage workspace-wide resources. For example, it can list the company’s users or retrieve appointments across the whole workspace by filtering on
userId.
- Act on behalf of another user. The
x-meetergo-api-user-idheader is a Platform API Key feature. A PAT request carrying that header for another user is rejected with403. - Manage the user lifecycle. Creating, deleting, or updating users requires a Platform API Key (or the dashboard).
- Create or manage credentials (other PATs, API keys) or trigger GDPR exports.
Building an organization-level integration? Create the PAT from a stable company admin account (for example
integrations@yourcompany.com) rather than a personal employee account. If the token’s owner is removed from the workspace, the token stops working.Creating a Personal Access Token
1
Navigate to Integrations
Go to my.meetergo.com/integrations and find the API card
2
Create a new token
Click Connect and give it a descriptive name (e.g., “Zapier”, “CRM Sync”)
3
Set expiration
Optionally choose an expiration period.
4
Copy immediately
The token is shown only once. Store it securely.
Example request
A PAT needs no extra headers. This request lists meeting types visible to the token owner:Platform API Key
A Platform API Key is owned by your company, not by an individual user. It is designed for applications that programmatically manage users and their scheduling: marketplaces, white-label integrations, telehealth or coaching platforms, recruitment software. Capabilities:- Create, update, and delete platform users programmatically
- Act on behalf of any user in your company via the
x-meetergo-api-user-idheader - Access availability, bookings, and meeting types across the organization
- Manage webhooks and real-time events
Need Platform API access? Book a demo to discuss your integration requirements. The API Platform plan is priced per booking and includes platform user types that do not count as workspace seats.
Creating a Platform API Key
1
Navigate to API Settings
Go to my.meetergo.com/admin/api-keys (Settings → API tab)
2
Create a new key
Click Create API Key and give it a descriptive name (e.g., “Production”, “Staging”)
3
Set expiration
Choose 1-90 days. Keys expire automatically for security.
4
Copy immediately
The key is shown only once. Store it securely.
The user context header
Because an API key is not a user, most endpoints need to know which user to act as. Pass that user’s ID in thex-meetergo-api-user-id header:
GET /v4/user/me) work without the header and then act as the company owner.
Get a user’s ID from
GET /v4/user (list users), from the userId returned when creating a user, or from GET /v4/user/me.Capability comparison
Required headers
Key management
Rotation
Both credential types support expiration. Plan rotation before a credential expires:- Create a new token or key before the old one expires
- Update your application to use the new credential
- The old credential stops working after expiration
Deactivating and revoking
- Personal Access Tokens: revoke at my.meetergo.com/integrations via the Revoke button.
- Platform API Keys: deactivate (temporarily) or revoke (permanently) at my.meetergo.com/admin/api-keys.
Error responses
Missing Authorization header
Invalid or expired credential
PAT with impersonation header
Returned when a Personal Access Token sendsx-meetergo-api-user-id for another user:
Missing user header (API key)
Acting user not in your company (API key)
Security best practices
Do
- Store credentials in environment variables or secrets managers
- Use different keys for development and production
- Rotate credentials regularly
- Monitor API usage for unexpected activity
- Use HTTPS for all requests (enforced by our API)
Don’t
- Commit credentials to version control
- Share credentials via email, chat, or insecure channels
- Log credentials in application logs
- Use the same credential across unrelated applications
- Store credentials in frontend JavaScript