OAuth Access Tokens

By default transactions are charged to, stored against, and searched for in the account of the certificate used to authenticate.

However systems can be given the authority to do transactions on behalf of other users.

An oAuthToken must be retrieved and then presented every time a transaction is done on behalf of a user. All transactions will be charged to, stored against, and searchable as if the user had done the transaction directly through MotorWeb.

This avoids the use case where you would need to store each customers certificate and password you wish to act on behalf of and would only need to utilise a single certificate (your own).

Requesting an OAuth Access Token

Users do not have the ability to generate a new OAuth token to act on behalf of another user. In order to generate a new or expired token, a user manager from your organisation would need to reach out to MotorWeb support at support@motorweb.co.nz with the following details:

  1. Your account name

  2. Your username

  3. Account name of business you wish to act on behalf of.

Caveats:

  • The requesting user must be a user manager under your organisations account.

  • The business you wish to act on behalf of must have a MotorWeb account.

  • If utilising services that return private owner information then the account you are acting on behalf of must have the relevant section 241 access approved and validated from NZTA.

Using an OAuth Access Token

  • An OAuth access token is passed via a query parameter: oAuthToken

    • e.g. /b2b/bvi/generate/4.0?plateOrVin=<plate>&oAuthToken=<access_token>

  • The oAuthToken query parameter must be passed with each API request.

  • We support the Code Grant grant type of the OAuth 2.0 open standard. One slight difference is that you must present to us your client certificate (your certificate still needs to be passed with each API request).

  • The transaction would then be linked (billed and stored against) the account in which the OAuth token is associate with.

  • The transaction will appear under the transaction history of the associated account.

  • If the token provided is either invalid, expired or the end user account has since been disabled then a BAD-ACCOUNT error will be returned.

Example:

cURL request with an access token:

curl --cert-type P12 --cert motorwebnz.p12:'PASSWORD' https://robot.motorweb.co.nz/b2b/bvi/generate/4.0?plateOrVin=<plate>&oAuthToken=<access_token>

  • Note the additional query parameter oAuthToken .

  • You would still need to pass your certificate with the request.

PreviousAuthenticationNextFuel Economy Labels

Last updated