Movik API

Before you start

You will have been given an email address and password for a service user created for your organization. Those credentials are the whole of your access: you exchange them for a short-lived token, and that token authorizes every request. There is no separate API key.

The service user is scoped to a single organization. Requests return and modify only that organization’s records, enforced in Movik’s data layer rather than by the endpoint you happen to call — so there is no request you can construct that reaches another customer’s data.

Base URLs

Every path in the reference is relative to a base URL. All traffic is HTTPS; plaintext HTTP is refused rather than redirected, so a request sent to http:// will fail rather than silently downgrade.

Quick start

The short version: send your credentials with each request to movik.us/api/partner/ and Movik handles the token for you. One line, nothing to store:

curl -u 'you@example.com:your-password' \
  https://movik.us/api/partner/fmcsa/carrier/3215521

That is the whole integration for most partners — Simple integration covers it, including client examples in three languages. The rest of this section describes the token-based alternative, for callers who would rather hold a token themselves.

The token-based alternative

Three steps. Substitute your own credentials.

1. Exchange credentials for a token

Post your service user’s email and password to Movik’s token endpoint. Note that this call goes to movik.us, not to the API host.

curl -X POST https://movik.us/api/integrations/token \
  -H 'Content-Type: application/json' \
  -d '{
    "email": "you@example.com",
    "password": "your-password"
  }'

The response carries the token and when it expires:

{
  "token_type": "Bearer",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_at": 1755640800000,
  "expires_in": 3600,
  "partner": { "id": "your-partner-id", "name": "Your Company" }
}

2. Call the API with the token

Send it as a bearer token in the Authorization header on every request.

curl https://api.dev.movik.us/account \
  -H "Authorization: Bearer $ID_TOKEN"

3. Re-mint before it expires

Tokens are short-lived — typically one hour. Read expires_at and mint a new token shortly before it passes. Do not mint one per request; cache it and reuse it until it is close to expiry.

Authentication has a complete client implementation that handles caching and refresh.

A worked example

The most common task for a marketing integration is looking up a carrier by DOT number before creating a record, so that what you post matches what FMCSA holds. That lookup needs no token, which makes it a good first request to prove connectivity:

# No Authorization header needed for FMCSA lookups
curl 'https://api.dev.movik.us/fmcsa/carrier/3215521'

Then create the profile with an authenticated call. See Signup and Organization for the fields each accepts.

Where to go next

• Authentication — the token lifecycle, error handling, and a reference client.
• Conventions — status codes, error shapes, content types and file uploads.
• Reference — 97 endpoints, grouped by domain in the sidebar.

Support

Integration questions go to support@movik.us. Include the request path, the response status and the apigw-requestid response header — that header identifies the exact invocation in our logs and turns a vague report into a two-minute lookup.