TELUS · Authentication Profile

Telus Authentication

Authentication

TELUS runs two completely different authentication models on its two publicly documented APIs. The Insights Location API uses OAuth 2.0 client credentials plus a mandatory customerId header; the TELUS Health CHR Enterprise API uses asymmetric, self-signed JWTs (RS512) where the consumer holds the private key and CHR holds the registered public key — there is no token endpoint and no client secret at all. Neither surface is self-serve: credentials on both sides are issued through a sales/onboarding process.

TELUS secures its APIs with oauth2 and http across 4 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the clientCredentials flow(s).

TelecommunicationsCanadaMobile Network OperatorBroadbandNetwork APIsCAMARAOpen GatewaySIM SwapIdentity VerificationLocation IntelligenceIoT5GHealthcareElectronic Medical RecordsGraphQLWebhooksGeospatial
Methods: oauth2, http Schemes: 4 OAuth flows: clientCredentials API key in: header

Security Schemes

InsightsOAuth2ClientCredentials oauth2
InsightsCustomerIdHeader apiKey
· in: header ()
CHRSelfSignedJWT http
scheme: bearer
CHREventNotificationSignature webhookSignature

Source

Authentication Profile

Raw ↑
generated: '2026-07-25'
method: searched
source: >-
  https://docs.insights.telus.com/ (TELUS Insights Location API, Postman Documenter) and
  https://help.inputhealth.com/en/collections/3317215-chr-enterprise-api (TELUS Health CHR
  Enterprise API). Cross-checked against the harvested Postman collection
  (collections/telus-insights-location-api.postman_collection.json, auth type oauth2) and the
  harvested GraphQL introspection document (graphql/telus-chr-enterprise-api-introspection.json).
description: >-
  TELUS runs two completely different authentication models on its two publicly documented APIs.
  The Insights Location API uses OAuth 2.0 client credentials plus a mandatory customerId header;
  the TELUS Health CHR Enterprise API uses asymmetric, self-signed JWTs (RS512) where the consumer
  holds the private key and CHR holds the registered public key — there is no token endpoint and no
  client secret at all. Neither surface is self-serve: credentials on both sides are issued through
  a sales/onboarding process.
summary:
  types: [oauth2, http]
  api_key_in: [header]
  oauth2_flows: [clientCredentials]
  jwt_bearer_self_signed: true
  self_serve_credentials: false
schemes:
- name: InsightsOAuth2ClientCredentials
  api: TELUS Insights Location API
  type: oauth2
  flow: clientCredentials
  token_url_published: false
  token_url_note: >-
    The token endpoint is not published anonymously. The documentation instructs the consumer to
    read oauth_token_endpoint, oauth_grant_type and oauth_scope from the "My Account" page of the
    TELUS Insights Portal (https://insights.telus.com).
  request_parameters: [grant_type, client_id, client_secret, scope]
  token_request_content_type: application/x-www-form-urlencoded
  access_token_use: 'Authorization: Bearer {access_token}'
  token_lifetime_seconds: 299
  token_reuse_guidance: >-
    "When getting an OAuth Token from the Token URL, it is preferable that you reuse the token for
    specified amount of expiry seconds (present inside the token JSON and set to 299 seconds). That
    prevents the identity system from being overwhelmed."
  scopes_published: false
  sources: [collections/telus-insights-location-api.postman_collection.json, https://docs.insights.telus.com/]
- name: InsightsCustomerIdHeader
  api: TELUS Insights Location API
  type: apiKey
  in: header
  parameter_name: customerId
  case_note: >-
    The published shell examples send the header lower-cased as `customerid`; the Postman collection
    sends `customerId` on count/shapefile/geofence/usage requests and `customerid` on the Job
    endpoints. HTTP header names are case-insensitive, so both are the same header.
  description: >-
    Tenant identifier that scopes every request to one customer. Documented as "the unique ID
    generated when 'Create Customer ID' is performed which creates the association of a customer with
    their unique API key." Required in addition to the bearer token on every operation.
  required: true
  sources: [collections/telus-insights-location-api.postman_collection.json]
- name: CHRSelfSignedJWT
  api: TELUS Health CHR Enterprise API
  type: http
  scheme: bearer
  bearerFormat: JWT
  header: 'Authorization: Bearer {json_web_token}'
  signing_algorithm: RS512
  key_material: >-
    2048-bit RSA key pair. The consumer generates it, keeps the private key, and registers the
    public key in PEM format in the "JWT Public Key" field of an API Consumer under
    Settings > Enterprise API in the CHR account.
  required_claims:
  - claim: iss
    requirement: Must match the Issuer value configured on the API Consumer record in CHR.
  - claim: exp
    requirement: Must expire within the next 15 minutes (900 seconds).
  token_endpoint: none
  client_secret: none
  notes:
  - There is no authorization server and no token exchange — the consumer mints its own token.
  - Every API action is audit-logged; requests and responses are retained for 90 days.
  - Access is a paid feature enabled per CHR account, gated by a Privacy & Security questionnaire.
  sources:
  - https://help.inputhealth.com/en/articles/6483215-chr-enterprise-api
  - https://help.inputhealth.com/en/articles/6483223-making-requests-to-the-api
  - https://help.inputhealth.com/en/articles/6483229-creating-api-consumers
- name: CHREventNotificationSignature
  api: TELUS Health CHR Enterprise API — Event Notification Service
  type: webhookSignature
  direction: inbound-to-consumer
  mechanism: >-
    The CHR signs each outbound event notification with a shared secret supplied by the consumer
    when creating the subscription; the resulting signature travels in a request header. The header
    name is not published in the help centre and was not verified.
  sources: [https://help.inputhealth.com/en/articles/7988802-chr-enterprise-api-event-notifications]
portal_authentication:
- name: TELUS Client Identity (PingFederate)
  where: api.telus.com API Marketplace and insights.telus.com portal sign-in
  type: oauth2
  flow: authorizationCode
  authorization_endpoint: https://auth-gateway.telus.com/as/authorization.oauth2
  scopes_observed: [ciiLogin, identityinfofulldetail, serviceassociation]
  note: Human browser sign-in for the portals, not an API grant. Discovery documents return 403 (Cloudflare).
not_found:
  openid_connect_discovery: No /.well-known/openid-configuration is reachable on any TELUS host.
  mtls: No mutual-TLS requirement is documented on either API.
  ciba: >-
    CIBA — the backchannel flow CAMARA specifies for network APIs — appears nowhere on a TELUS
    property; TELUS publishes no first-party CAMARA endpoint.