Skip to main content

Partner Access Tokens in 340B ESP

Learn about partner access tokens and how to obtain them

Access tokens allow covered entities to grant Partners the permissions needed to submit and retrieve data through the API and SDKs. Partners must obtain access tokens through 340B ESP Support before any covered entity can authorize them for access.


What are Partner Access Tokens?

Partner access tokens are unique identifiers issued during Partner onboarding. These tokens allow a covered entity to formally associate a Partner with their 340B ESP account and determine what the Partner can do on their behalf.

Access tokens do not authenticate API calls themselves — authentication is handed using a separate private token. Instead, tokens act as a link that lets covered entities grant a Partner permissions.


How Partners Obtain an Access Token

Partners can obtain an access token by completing onboarding with 340B ESP Support, at which time 340B ESP verifies the Partner organization and issues both an access token and private token directly to the Partner.

  • Access Token – Partners share with covered entities so covered entities can grant them permissions to access data through API.

  • Private Token – A secure credential Partners use to authenticate their API request to 340B ESP, which should not be shared.

Partners must have both tokens and use them correctly for successful, authorized API and SDK interactions.


Error Code 51: Invalid Perms or Permission File Missing

This error means the TPA's submission attempt does not have a valid, currently recognized access token on file for the covered entity it is submitting for. This can happen for a few reasons:

  • The access token was never generated or provided to the TPA.

  • The access token was generated for a different 340B ID than the one the TPA is attempting to submit under.

  • The token exists but has not been correctly loaded into the TPA's own submission system on their end.

Because this error depends on configuration inside the TPA's own system (which 340B ESP cannot see), Fin should confirm the token was generated and shared correctly on the 340B ESP side, then escalate if the covered entity confirms the token is correct — the remaining troubleshooting is on the TPA's system, not something 340B ESP support can diagnose remotely.


Still have questions?

If you have questions or need additional help, our team is here for you — please feel free to reach out using any of the contact options below:

Chat: Available via in-app messenger
​Email: [email protected]

Did this answer your question?