How to Get a USPS CRID and MID, and Link Them to the v3 API (2026)

Creating a shipping label with the USPS v3 REST API takes three identifiers: a Customer Registration ID (CRID), a Mailer ID (MID), and an Enterprise Payment Account (EPA). Then it takes linking them together through a portal USPS barely documents.

Since August 1, 2026 there is a fourth requirement, and it caught people who were already live: a signed Addresses API license, gating address validation. That used to be the one part of USPS that just worked. USPS now states it plainly on the developer portal: “Customers who did not complete onboarding no longer have access to the Addresses API.”

Every identifier below is a placeholder. Substitute your own.

Which portal owns what

Three USPS systems, three logins, three different hosts. Knowing which one owns the thing you are missing is most of the work.

The third one goes by two names in USPS’s own documentation. “Business Portal” and “Customer Onboarding Portal” are the same site at cop.usps.com, which is worth knowing before you spend twenty minutes hunting for a fourth login.

What CRID, MID, and EPA actually are

USPS uses these identifiers to track who is creating labels and manifests through the API. They serve different purposes, and label creation needs all three.

Tracking (GET /tracking/v3/tracking) and pricing (POST /prices/v3/total-rates/search) work on OAuth credentials alone, with no CRID, MID, or EPA. Address validation (GET /addresses/v3/address) also works on OAuth credentials, but now needs its own license behind them. Label creation and manifests need the full set.

The 403 problem

The most common confusion we see: everything works for address validation and tracking, but label creation returns a 403 or 401.

Works on OAuth credentials alone: address validation, city/state lookup, ZIP code lookup, tracking, pricing, locations, service standards.

Requires CRID + MID + EPA: label creation, payment authorization, SCAN forms (manifests), carrier pickup scheduling, package intercept.

The USPS Developer Portal grants Public Access I by default. That bundle covers OAuth, addresses, pricing, tracking, and a handful of other read-only endpoints. It does not include Labels or Payments. Those require separate enrollment and a manual approval from USPS, with no self-service option.

The Addresses API license (since August 1, 2026)

This section did not exist in the first version of this guide. Until this summer, address validation needed nothing but a developer account.

Effective August 1, 2026, USPS moved the Enhanced Addresses API onto a consumption-tier pricing model and conditioned access on a signature: “Access to the Addresses API and webhooks requires a signed license agreement.” The fee curve is $10 flat for up to 2,000 lookups a month, then $4.50, $4.25, and $4.00 per 1,000 as volume climbs, billed at a single tier on total monthly consumption with partial thousands rounding up. Charges arrive as an “Addresses Usage Fee” debited from your EPA at the start of each month for the prior month. Figures from the USPS Addresses API Tech Sheet, updated 2026-08-13.

This is retroactive in effect, not just prospective. Existing integrations that never completed onboarding lost access rather than being grandfathered. If v3 address calls that worked in July are failing now, the license is the first thing to check and no code change will fix it.

USPS publishes nine steps. Here they are with what each one actually involves:

1. Review developer resources. The USPS GitHub page carries Postman collections and sample cURL commands. Worth ten minutes before you touch the portal, because the request shapes are not obvious from the spec alone.
2. Create or log into your USPS COP account. This is the Business Portal, not the Developer Portal and not your BCG login from 2019. If you have used USPS APIs before, you probably already have one and have forgotten it.
3. Set up and fund an Enterprise Payment Account. Trust, ACH debit, or credit card. This is the step people defer and then get stuck behind, because the license request cannot complete without a funded account, and ACH verification is measured in business days.
4. Accept the updated Terms and Conditions. Business Portal → My Apps → Developer Apps → Manage. It is a checkbox, and it is easy to walk past.
5. Start the license request. At cop.usps.com: My Account → API Licenses → Add an Addresses API License. This exact path is the one USPS links from its own developer portal.
6. Sign via DocuSign. USPS emails an order form and the license agreements after you complete the portal steps. Your signature is the fast half.
7. Link your API credentials, after USPS countersigns. Quick Actions → API Licenses → Set up Addresses on the License → Select Credentials → Finalize Setup. If the license status reads Pending, signatures are still in progress on one side or the other.
8. The effective date is August 1, 2026. Signed licenses take effect then regardless of when they are signed.
9. Request TEM access to test. Call https://apis-tem.usps.com/addresses/v3/address with your production credentials. If USPS previously issued you a secondary credential set through EmailUs, you can stop using it.

What the process is actually like

The portal steps are an afternoon. The countersignature is not.

Steps 1 through 6 are ordinary enterprise onboarding: forms, a checkbox, a DocuSign envelope. What the numbered list does not convey is that step 7 has a hard dependency on a human at USPS, and there is no published SLA for it, no queue position, and no notification other than the DocuSign completion email. The portal’s only signal is a status field reading Pending, which means the same thing on day one as on day twenty.

Our own order form went out and came back fully executed, USPS-countersigned, on August 18, 2026. Between signing and countersignature, the correct action is nothing. Resubmitting the license request creates a second envelope rather than accelerating the first.

Three details cost us time and are worth stating plainly:

Countersignature is not access. After USPS countersigns, you still have to link credentials to the license, refresh your claims, and refresh your OAuth token. Three separate actions, none automatic, all of which look like they should be.

An existing token will not pick up the license. Claims are baked in at issue. If you refresh claims but keep calling with the token you already had, nothing changes and it looks like the license did not apply.

Fund the EPA before you need it, not when you need it. ACH verification runs 2–3 business days, and it sits on the critical path for both the license and label creation.

Step-by-step: CRID registration

Your Customer Registration ID is issued through the USPS Business Customer Gateway (BCG). Not a personal USPS.com account, and not the Developer Portal.

1. Create a BCG business account. Go to gateway.usps.com and click Sign Up. Select Business account type. You need your company’s legal name, physical address, and EIN. Do not use an SSN. The “business not found” error during registration almost always means an SSN was entered instead of an EIN.
2. Open Mailing & Shipping Services. In the BCG dashboard, look for it in the left navigation or under Quick Actions. All enrollment happens there.
3. Apply for Customer Registration. The application asks for your business address, contact info, and the types of mailing you plan to do. Select “Ship with APIs” or “eVS” if you see those options.
4. Wait for approval. Issuance is typically 1–3 business days, often instant. You get an email with an 8-digit numeric CRID, which goes in every label creation request.

Step-by-step: MID registration

Your Mailer ID also comes from BCG. You want at least one for label creation. Businesses that also do bulk mailings often take a second to keep those streams separate.

1. Go to Mailer ID in BCG. Under Mailing & Shipping Services, click “Apply for Mailer ID.”
2. Choose 6-digit or 9-digit. A 6-digit MID is for high-volume mailers sending 10,000+ pieces a year and provides a larger range of tracking number sequences. A 9-digit MID is for standard volume and is what most API-only businesses get; it works identically for label creation. You can request a 6-digit later if volume grows.
3. Link the MID to your CRID. The application asks you to associate it. That linkage is what lets USPS tie labels to your business entity.
4. Approval timeline. Usually same day to 2 business days. The MID appears in BCG under “My Mailer IDs” and goes in the senderInfo.MID field.

Step-by-step: EPA setup

The EPA is your postage payment account. Without it, USPS has no way to charge for the labels you create.

1. Open Enterprise Payment System. In BCG, under Mailing & Shipping Services, find “Enterprise Payment System” or “EPS” and click Enroll.
2. Link to your CRID. The EPA account number is 10 digits (placeholder: 1000000000) and goes in paymentInfo.accountNumber.
3. Set up funding. ACH bank transfer or debit. USPS initiates micro-deposits, two transfers under $1.00, to verify. This takes 2–3 business days, and you must confirm the exact amounts before the account activates.
4. Check approval status. “USPS Ship Account Management” in your BCG services list shows Approved once micro-deposits are verified.

COP claims linking, the hidden step

This is the step that causes the most frustration. You have a CRID, a MID, an EPA, and a Developer Portal app with valid OAuth credentials. Address validation works. Tracking works. Label creation returns 401 Insufficient OAuth scope.

The reason: your Developer Portal app has to be linked to your CRID, MID, and EPA through the Customer Onboarding Portal (COP), a separate system from both BCG and the Developer Portal, and one USPS barely mentions in its documentation.

1. Request Labels and Payments API access. Go to emailus.usps.com/s/web-tools-inquiry, select “USPS APIs” then “Customer Access.” Ask for Payments v3, Domestic Labels v3, and Subscriptions-Tracking on your app. Include app name, CRID, MIDs, and EPA account number. USPS responds in 1–4 weeks, usually with a Google Forms questionnaire. Fill it out immediately.
2. Go to COP Navigator. After the grant, sign in at cop.usps.com with BCG credentials, open “My Apps,” and find your Developer Portal application.
3. Refresh Claims. This pulls CRID, MID, and EPA into the COP authorization system. Check “My Authorizations” afterward. Your CRID and MIDs should be listed. Zero authorizations means the Labels and Payments product has not been granted yet.
4. Verify your JWT. Request a new OAuth token and base64-decode the payload. Your CRID, MIDs, and EPA account number should be in the claims. If api_products still reads [Public Access I], the grant has not propagated.

{
"aud": ["payments", "prices", "labels"],
"payment_accounts": {
  "accounts": "1000000000"
},
"mail_owners": [{
  "crid": "12345678",
  "mids": "900000000, 900000001"
}],
"company_name": "YOUR COMPANY LLC",
"api_products": "[Public Access, Labels, Payments]"
}

// If "api_products" only shows "[Public Access I]",
// submit the service request in step 1 above.

Using CRID and MID in requests

OAuth token request

Your scope must include labels and payments alongside the standard scopes:

POST https://apis.usps.com/oauth2/v3/token

# Request body (x-www-form-urlencoded)
grant_type=client_credentials
&client_id={your_client_id}
&client_secret={your_client_secret}
&scope=addresses prices labels payments tracking

# "labels" and "payments" only work AFTER USPS grants your app
# the Labels & Payments product. Default "Public Access I" excludes them.

Label creation request

CRID goes in the request header and in senderInfo. MID goes in senderInfo. EPA goes in paymentInfo:

POST https://apis.usps.com/labels/v3/label
Authorization: Bearer {access_token}
Content-Type: application/json
X-USPS-CRID: 12345678

{
"imageInfo": {
  "imageType": "PDF",
  "labelType": "4X6LABEL"
},
"toAddress": {
  "streetAddress": "1600 Pennsylvania Ave NW",
  "city": "Washington",
  "state": "DC",
  "ZIPCode": "20500"
},
"fromAddress": {
  "streetAddress": "123 Main St",
  "city": "New York",
  "state": "NY",
  "ZIPCode": "10001"
},
"packageDescription": {
  "weight": 2.5,
  "mailClass": "PRIORITY_MAIL",
  "processingCategory": "NON_MACHINABLE"
},
"senderInfo": {
  "MID": "900000000",
  "CRID": "12345678"
},
"paymentInfo": {
  "paymentMethod": "USPS_ACCOUNT",
  "accountType": "EPS",
  "accountNumber": "1000000000"
}
}

Manifest / SCAN form request

MID and CRID are top-level fields:

POST https://apis.usps.com/scan-forms/v3/scan-form
Authorization: Bearer {access_token}
Content-Type: application/json

{
"MID": "900000000",
"CRID": "12345678",
"manifestDate": "2026-03-10",
"trackingNumbers": [
  "9400111899223456789012",
  "9400111899223456789029"
]
}

Common enrollment errors and fixes

Complete enrollment checklist

The full sequence from zero to label creation. Some steps run in parallel; the dependencies are strict where noted.

1. BCG business account — create at gateway.usps.com with EIN. (Day 1)
2. CRID — apply via BCG. (Day 1–3)
3. MID — apply via BCG, link to CRID. (Day 1–3, parallel with CRID)
4. EPA — enroll via BCG, add ACH funding, confirm micro-deposits. (Day 1–5)
5. Developer Portal app — create at developers.usps.com for Client ID and Secret. (Day 1, instant)
6. Addresses API license — request in the Business Portal, sign via DocuSign, wait for USPS to countersign. (Depends on both legal departments)
7. Service request for Labels & Payments — email USPS to add products to your app. (Day 1–28, depends on USPS response time)
8. COP claims linking — after the grant, refresh claims at cop.usps.com, then request a new token. (After steps 6 and 7)
9. Test — run the TEM address endpoint and the non-production label flow before buying live postage. (After step 8)

Realistic timeline: with a fast USPS response, labels in 1–2 weeks. A slow product grant pushes it to 3–4 weeks. Steps 6 and 7 are the bottlenecks, and neither one has an SLA you can plan against.

USPS escalation contacts

If your service request goes unanswered, work down this list and follow up weekly. Reference the original case number every time, because a fresh request restarts the queue rather than escalating it.

The phone line is the fastest way to learn whether a request exists in the system at all, which is a different question from whether it has been worked.

What RevAddress does about all this

The line between what needs a USPS license and what does not is clean.

Free tier, no USPS license required. Standardization, geocoding, and address extract run against the US Census Bureau’s public address inventory. 1,000 requests a month, no credit card, no BCG account, no DocuSign. It puts an address in correct postal form and returns street-level coordinates. It does not return DPV, ZIP+4, or USPS deliverability flags, because those are USPS data and USPS data requires a license.

The full USPS suite, on your license. You complete the enrollment above, then point RevAddress at your credentials. DPV, ZIP+4, CMRA and vacancy flags, rates, service standards, and tracking all run against your own USPS account. We manage the OAuth lifecycle, rate-limit budgeting, caching, and retries; the CRID, the MID, the EPA, and the USPS relationship stay yours. Available on every plan, including Free.

Labels run on your license, not ours. We do not create labels on our credentials for you. Postage is paid by the entity that owes it, which means your EPA, your CRID, your MID. Anyone offering otherwise is either reselling under terms worth reading closely or describing something they have not shipped.

Start here

• Get a free API key — standardization, geocoding, and address extract today, 1,000 requests a month, no BCG account and no DocuSign
• Every OAuth error and its fix — 401, 403, 429, and the two-token flow
• What the v3 API costs — the consumption tiers and the license that gates them
• Surviving the 60-per-hour rate limit — caching, queueing, and increase requests
• USPS Web Tools shutdown — what broke in January and the endpoint mapping