The MyGeotab software development kit (SDK) provides APIs and client libraries for working with the same data and workflows used by MyGeotab. You do not need a separate developer API key. You need a MyGeotab database, an appropriately scoped user, and an integration design that accounts for permissions, data volume, recovery, and side effects.

Preparing a test environment

Develop in a test database with test users and entities. API calls use a real database, including calls made by the API Runner and live samples. A write or removal made through these tools has the same effect as a call from a production integration.

  1. Use an existing test database, or register a database.
  2. Create a dedicated API user. Grant only the security clearances and data-access groups required for the use case so that testing reflects the integration's production scope.
  3. Add test devices or other test entities only when the use case needs them. See the Geotab Support Documentation for device installation instructions.
  4. Keep the database name, user name, and password in a secret store. Do not commit or log credentials.
Choosing a starting path

Choose the path that matches the behavior you are building:

  • For a server-side integration, start with Designing Reliable Integrations, then select the supported client for your language.
  • For a workflow inside MyGeotab or Geotab Drive, start with Developing Add-Ins.
  • For continuous operational synchronization, read the Data Feed guide before implementing GetFeed.
  • For large analytical or historical workloads, evaluate the Data Connector before building an API polling service.

Use the method reference and entity reference after choosing the access pattern. The reference describes the contract; the guides explain how the pieces work together in a reliable application.

Making a first call
  1. Open the API Runner and sign in to the test database with the dedicated API user.
  2. Make a read-only Get call for an entity the user can access. Add a supported search, a small resultsLimit, and a PropertySelector when the entity supports it.
  3. Confirm that the result contains only data within the user's expected scope.
  4. Repeat the call using the JavaScript, .NET, or Java client.

Start with reads. Before using Add, Set, or Remove, add an explicit test-database guard and understand the entity's lifecycle. Remove is permanent for supported entity types.

Preparing for production

A successful first response proves connectivity, not production readiness. Before deploying:

  • Handle the server path returned by authentication and reuse the session instead of authenticating before every call.
  • Bound high-volume reads, paginate supported entities, and avoid resolving referenced entities one record at a time.
  • Retry only transient failures, using bounded exponential backoff with jitter and the server's retry guidance.
  • Make feed processing and uncertain write recovery idempotent.
  • Test with the production API user's clearances and data scope, including empty and partial results.
  • Record sanitized request context, latency, rate-limit responses, feed lag, and server error IDs.

The production checklist turns these requirements into concrete tests.

Getting help

Search the Geotab Community for implementation questions and known solutions. When requesting help, include the method and entity type, the sanitized parameters, the server-provided error ID, and the API client version. Do not include passwords, session IDs, tokens, or customer data.

Track the MyGeotab release notes and subscribe to Geotab technical bulletins for changes that can affect an integration.