How-To

Best Practices for API Users and Custom Services

August 28, 2015 | by

Marketo’s REST APIs use custom services for authentication and each of these services is owned by an API-only Marketo user. The capabilities of each custom service are determined by the permissions of each role assigned to that user. Allocating individual users and custom services to your integrations gives you multiple benefits:

  • You can fine-tune the permissions given to each individual service through the role given to your user.
  • You can disable individual web services from making calls to your instance by deleting the corresponding custom service, without disabling others.
  • Reporting on API call usage will be broken down by user, allowing you to identify high and abnormal utilization
  • It is easier to determine what data each web service is being given access to
  • Workspace-enabled instances can restrict access to specific business units, by only awarding roles to accessible workspaces

API Usage

Each of your API users is reported individually in the API usage report, so splitting up your web services by user allows you to easily account for the usage of each of your integrations. If the number of API calls to your instance are exceeding the limit and causing subsequent calls to fail, using this practice will allow you to account for the volume from each of your services and let you evaluate how to resolve the issue. See your usage by going to Admin -> Web Services and clicking on the number of calls in the past 7 days. You can also get the same information from the Usage APIs

API
Per Users

Disable a Service

If an integration is having undesirable effects, it can be tedious and difficult to disable if you have not assigned each one an individual custom service. Having them broken out one by one makes it as easy as deleting the offending service in your Admin -> Launchpoint.

Delete Service

Workspace Management

For Marketo Enterprise subscriptions, it is common for a service to only need access to a single workspace, and this can be enforced by role assignment to the API User. Each user role can be assigned either globally, or on a per-workspace basis, so access can be restricted in workspaces wherever appropriate, providing the most minimal permissions set possible.