Version 4.0.0 of project44's API. If you're not familiar with project44, we recommend checking out our guides first: https://developers.project44.com/guides/shippers and https://developers.project44.com/guides/carriers.
Version 4.0.0 of project44's API. If you're not familiar with project44, we recommend checking out our guides first: https://developers.project44.com/guides/shippers and https://developers.project44.com/guides/carriers.
API used for registering and managing OAuth 2.0 client applications. See the "Authentication" section above for more information. To authorize API requests to project44 for an API integration, first your client application must be registered with project44, which will issue your application a client id and secret. These credentials can then be used to generate bearer tokens, which can be included on all other API requests to authorize your client application. The client application is authorized through the project44 user management UI as a machine user with username "app-{client_id}@client-applications.project44.com".
An admin user (with Movement user role "Customer Admin") must use HTTP Basic Authentication with this API to manage client applications. Basic Authentication is deprecated for all other APIs, besides token generation, in favor of passing the access token generated via OAuth 2.0.
API for OAuth 2.0 token generation. See the "Authentication" section above for more information. Once your client application is registered, you can use the token generation endpoint to authenticate with your application's client id and secret in exchange for a bearer token to be included on all other API requests to authenticate as that client application. The client application is authorized through the project44 user management UI as a machine user with username "app-{client_id}@client-applications.project44.com".
To generate an access token, you may authenticate your client application by providing its client id and secret either in the body of the request or in the form of HTTP Basic Authentication (but you may not use both ways in the same request).
Authenticate with your client application's credentials (id and secret) to generate a new project44 access token. The resulting access token can be used as a bearer token to access your project44 account and data via project44's other APIs, while acting as that client application.
You may authenticate your client application either by passing the id and secret via HTTP Basic Authentication (via the "Authorization" HTTP header) or via the client_id and client_secret fields in the POST request body with no "Authorization" header included. You may not use both approaches to authenticate the same request.
The POST request body must contain the request fields as URL-encoded parameters (a URL-encoded form) and must have the "Content-Type" HTTP header set to "application/x-www-form-urlencoded".
The id of the client application, generated and assigned by project44 via the OAuth 2.0 client applications APIs.
The secret part of the client application's credentials, generated and assigned by project44 via the OAuth 2.0 client applications APIs.
curl -i -X POST \ -u <username>:<password> \ https://na12.api.project44.com/api/v4/oauth2/token \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d client_id=string \ -d client_secret=string \ -d grant_type=client_credentials
OK
The project44 access token, which can be passed as a bearer token to all other project44 endpoints to have your client application's requests authorized. Pass the "Authorization" HTTP header to other endpoints in this form: "Authorization: Bearer {access_token}". Your client application can be granted roles and permissions via the project44 user management UI under user "app-{client_id}@client-applications.project44.com".
The time in seconds for which the access token will be valid before expiring. Tokens currently last approximately 12 hours, but this is subject to change by project44 in the future. Tokens should be reused by your application to the fullest extent possible for performance and security reasons by storing the token in a secure cache. Instead of using this expiration time to know when to generate a new access token, simply make requests with the token until project44 responds with a "401 Unauthorized" HTTP status code, at which point your application should generate and cache a new one.
{ "access_token": "string", "expires_in": 0, "token_type": "BEARER" }