EasyPost User Management API Guide

Auth method: HTTP Basic Auth (API key as username, empty password)

Setup steps

1. Log in to the EasyPost dashboard and navigate to API Keys.
2. Copy your Test or Production API key.
3. Pass the API key as the HTTP Basic Auth username with an empty password, or set the Authorization header as 'Authorization: Basic base64(API_KEY:)'.
4. Use the Production key for live operations; use the Test key for sandbox/testing.

Retrieve current user

• Method: GET
• URL: https://api.easypost.com/v2/users
• Watch out for: Returns the authenticated user's own record. Use the Production API key to see live data.

Request example

GET /v2/users
Authorization: Basic {base64(API_KEY:)}

Response example

{
  "id": "user_abc123",
  "object": "User",
  "name": "Acme Corp",
  "email": "admin@acme.com",
  "balance": "100.00"
}

Update current user

• Method: PUT
• URL: https://api.easypost.com/v2/users/{id}
• Watch out for: The user ID in the path must match the authenticated user's ID; you cannot update other top-level accounts.

Request example

PUT /v2/users/user_abc123
{
  "user": {
    "name": "Acme Corp Updated",
    "phone_number": "555-1234"
  }
}

Response example

{
  "id": "user_abc123",
  "name": "Acme Corp Updated",
  "phone_number": "555-1234"
}

Create child user

• Method: POST
• URL: https://api.easypost.com/v2/users
• Watch out for: Child users are sub-accounts under the authenticated parent. They share the parent's carrier accounts unless configured separately.

Request example

POST /v2/users
{
  "user": {
    "name": "Child Account",
    "email": "child@acme.com"
  }
}

Response example

{
  "id": "user_child456",
  "object": "User",
  "parent_id": "user_abc123",
  "name": "Child Account",
  "email": "child@acme.com"
}

Retrieve child user

• Method: GET
• URL: https://api.easypost.com/v2/users/{id}
• Watch out for: Must authenticate as the parent account to retrieve child user details.

Request example

GET /v2/users/user_child456
Authorization: Basic {base64(PARENT_API_KEY:)}

Response example

{
  "id": "user_child456",
  "parent_id": "user_abc123",
  "name": "Child Account"
}

Delete child user

• Method: DELETE
• URL: https://api.easypost.com/v2/users/{id}
• Watch out for: Only child users can be deleted via API. Top-level accounts cannot be deleted through the API.

Request example

DELETE /v2/users/user_child456
Authorization: Basic {base64(PARENT_API_KEY:)}

Response example

HTTP 204 No Content

Retrieve API keys

• Method: GET
• URL: https://api.easypost.com/v2/api_keys
• Watch out for: Returns both test and production keys for the authenticated user and all child accounts. Guard this endpoint carefully.

Request example

GET /v2/api_keys
Authorization: Basic {base64(API_KEY:)}

Response example

{
  "id": "user_abc123",
  "keys": [
    {"object": "ApiKey", "key": "EZAK...", "mode": "production"}
  ],
  "children": []
}

Update child user

• Method: PUT
• URL: https://api.easypost.com/v2/users/{id}
• Watch out for: Authenticate as the parent account when updating child user fields.

Request example

PUT /v2/users/user_child456
{
  "user": {
    "recharge_amount": "50.00",
    "recharge_threshold": "10.00"
  }
}

Response example

{
  "id": "user_child456",
  "recharge_amount": "50.00",
  "recharge_threshold": "10.00"
}

List child users

• Method: GET
• URL: https://api.easypost.com/v2/users/{id}/children
• Watch out for: Pagination uses cursor-based before_id parameter. has_more indicates additional pages.

Request example

GET /v2/users/user_abc123/children?page_size=20
Authorization: Basic {base64(API_KEY:)}

Response example

{
  "children": [
    {"id": "user_child456", "name": "Child Account"}
  ],
  "has_more": false
}

• Rate limits: EasyPost does not publish explicit per-plan rate limits in its public documentation. Rate limiting exists and is enforced server-side; exceeding limits returns HTTP 429.
• Rate-limit headers: No
• Retry-After header: Yes
• Rate-limit notes: HTTP 429 is returned when rate limits are exceeded. Retry-After header may be present. Contact EasyPost support for specific limits on high-volume accounts.
• Pagination method: cursor
• Default page size: 20
• Max page size: 100
• Pagination pointer: page_size / before_id

• Webhooks available: Yes
• Webhook notes: EasyPost supports webhooks for shipment and tracker events. There are no dedicated user-management webhook events (e.g., user created/deleted).
• Alternative event strategy: Poll GET /v2/users/{id}/children for child account changes.
• Webhook events: tracker.created, tracker.updated, payment.created, refund.successful, batch.created, batch.updated, scan_form.created, insurance.purchased, insurance.cancelled, insurance.failed

• SCIM available: No
• SCIM version: Not documented
• Plan required: N/A
• Endpoint: Not documented

Limitations:

• EasyPost does not offer a SCIM 2.0 API.
• No SSO/IdP integration (Okta, Entra, Google Workspace) is documented.
• User provisioning must be done via the EasyPost REST API directly.

Three automation scenarios are well-supported by the API. First, tenant provisioning: authenticate as the parent, POST to /v2/users with name and email, store the returned id and auto-generated API keys, then optionally set recharge_amount and recharge_threshold via PUT. Child accounts share the parent's billing by default, so recharge configuration is a required step in any production provisioning flow.

Second, API key auditing: a single GET /v2/api_keys call returns keys for the parent and all children. Iterate the children array to map each child id to its test and production keys. This endpoint's broad scope makes it a high-value target - restrict it at the application layer in multi-tenant deployments.

Third, deprovisioning: confirm the child user ID via GET, then DELETE /v2/users/{child_id}. A 204 response confirms permanent removal. This operation is irreversible and removes all associated shipment history and API keys for the child account - there is no soft-delete or recovery path via API.

Provision a child account for a new tenant

1. Authenticate with the parent account's Production API key.
2. POST /v2/users with name and email to create the child user.
3. Store the returned child user id and auto-generated API keys.
4. Optionally PUT /v2/users/{child_id} to set recharge_amount and recharge_threshold.
5. Distribute the child's API key to the tenant for their own API calls.

Watch out for: Child accounts share the parent's billing by default. Ensure recharge thresholds are set to avoid unexpected charges to the parent balance.

Retrieve and audit all child API keys

1. Authenticate with the parent account's Production API key.
2. GET /v2/api_keys to retrieve keys for the parent and all children.
3. Iterate the children array in the response to map each child ID to their test/production keys.
4. Log or store keys securely for audit purposes.

Watch out for: This single endpoint exposes all child keys simultaneously. Limit who can call this endpoint in your application.

Deprovision a child account

1. Authenticate with the parent account's Production API key.
2. Confirm the child user ID via GET /v2/users/{child_id}.
3. DELETE /v2/users/{child_id} to permanently remove the child account.
4. Verify HTTP 204 response confirming deletion.

Watch out for: Deletion is permanent and cannot be undone via API. All shipment history and API keys for the child are removed.

The primary integration trap is assuming that removing a dashboard team member completes the offboarding process. It does not. API keys issued to or used by that member remain active until explicitly rotated or deleted via the API Keys section.

There is no automated key revocation tied to team member removal, and no audit log to surface which keys a removed member had access to.

A second trap is pagination: EasyPost uses cursor-based pagination (before_id), not offset. Any integration that assumes offset pagination will silently miss records after the first page. Store the last returned id and pass it as before_id on subsequent requests; check has_more to determine whether additional pages exist.

For teams building on top of EasyPost with an MCP server with 60+ deep IT/identity integrations, the absence of SCIM and webhook coverage for user lifecycle events (no user.created or user.deleted events exist) means child account state must be tracked by polling GET /v2/users/{id}/children rather than reacting to push notifications. Design your sync layer accordingly.