Skip to main content

​
1. Get access

Make sure your team can sign in to the Terminal Dashboard. It’s where you manage API keys, provider configuration, and set up your Terminal Link. You’ve been sent Dashboard invites when your application was provisioned. If anyone on your team still needs an invite, ask an admin on your team who already has access. Once you’re in, open API keys with the environment set to Sandbox, then work through the Quickstart to make your first test connection. Make sure you also know how to reach us:
  • Email: send support issues and questions to support@withterminal.com, or cc it when emailing your Terminal points of contact. Everything sent there lands in our ticket tracking, so nothing gets lost and the right person on our team picks it up quickly.
  • Shared channel: we support shared Slack and Microsoft Teams channels with your team. If you don’t have one yet, or need a teammate added to it, just ask us. Questions and issues raised in the channel automatically land in our ticket tracking too.

​
2. Models you plan to use

All provider data is normalized into Common Models, so your integration works the same regardless of which provider a fleet is on. Review the models and decide which ones you need. Plans include different scopes of models. If you’re not sure which ones yours covers, ask your Terminal contact to confirm before you build against them.

​
3. Your customers’ providers

Look up each provider your customers run in the Provider Explorer to see the models and data it supports. To limit which providers your customers see in Link, set an include or exclude list with Provider Access Control. Decide how customers reach Terminal Link: the SDK embedded in your app, or the Hosted Page you send to fleets directly. Consent Templates let you run different flows for different products or customer segments. Link shows your application’s branding to every fleet you onboard, so upload your logo in the Dashboard under Settings > Branding. See Adding Your Logo.

​
5. Which events you react to

Webhooks tell you when a connection is created, a sync finishes, or data changes, so you aren’t left polling. Decide which events your systems need.

​
6. How connections map to your system

Every connection gets a Terminal connection ID, and that ID is enough on its own. If you’d rather use an ID you already have, set an externalId or tags with Custom Identifiers. Use tags when several of your records point at one connection. A unique externalId per record creates a separate connection for the same fleet, since it feeds duplicate connection detection.

​
7. Working towards a Production release

Everything above builds toward the Production Readiness checklist, which covers the consent flow, connection lifecycle, data access, webhooks, and billing. It’s where your development ends, so work through the guides and your own development and QA process first, and treat the checklist as the standard you’re building toward. Once you’re confident you’ve covered all of it, let your Terminal contact know. We’ll go through it with you and help provision your production environment.