Appgain · Authentication Profile

Appgain Authentication

Authentication

Appgain secures its APIs with apiKey across 6 declared security schemes, as derived from its OpenAPI definitions.

CompanyMobile MarketingMarketing AutomationOmnichannel MessagingPush NotificationsSMSEmailWhatsAppCustomer Data PlatformDeep LinkingCustomer EngagementAI AgentsConversational AIMENA
Methods: apiKey Schemes: 6 OAuth flows: API key in: header, query

Security Schemes

appApiKey apiKey
· in: header ()
appApiKeyQuery apiKey
· in: query ()
parseApplicationId apiKey
· in: header ()
parseMasterKey apiKey
· in: header ()
whatsappAuthorization http
scheme: bearer
whatsappAuthToken apiKey
· in: header ()

Source

Authentication Profile

Raw ↑
generated: '2026-08-13'
method: searched
source: >-
  postman/appgain-omnichannel.postman_collection.json (verbatim public collection
  4679101/T17KeScV) + https://docs.appgain.io/restAPI/introduction/ +
  https://docs.appgain.io/integrations/n8n-integration/ + live unauthenticated probes
docs: https://docs.appgain.io/restAPI/introduction/
summary:
  types: [apiKey]
  api_key_in: [header, query]
  oauth2_flows: []
  openid_connect: false
  mutual_tls: false
  notes: >-
    Appgain's REST surface is API-key only. A per-project application key is sent in
    an `appApiKey` request header (lowercase `appapikey` in the notify.appgain.io
    examples) and the tenant is selected by a `projectId` path segment. There is no
    OAuth 2.0 authorization server, no OIDC discovery document, no token endpoint and
    no scope surface anywhere in the published contract — /.well-known/oauth-authorization-server
    and /.well-known/openid-configuration miss on every host (see
    well-known/appgain-well-known.yml). Two SECONDARY credential systems exist behind
    the same platform: the Parse Server backend cloud functions, which take Parse
    application-id/master-key headers, and the WhatsApp Business vendor path, which
    additionally carries bearer-style JWTs. Neither is a scoped OAuth flow.
schemes:
- name: appApiKey
  type: apiKey
  in: header
  parameter_name: appApiKey
  aliases_observed: [appapikey]
  description: >-
    Per-project application API key. The primary credential for every messaging,
    smart-link, media and event-logging call. Issued in the Appgain dashboard under
    Project Settings -> API and SDK Keys.
  used_by_hosts: [api.appgain.io, notify.appgain.io, automator.appgain.io, '{account_subdomain}.appgain.io']
  sources: [postman/appgain-omnichannel.postman_collection.json, 'https://docs.appgain.io/restAPI/introduction/']
- name: appApiKeyQuery
  type: apiKey
  in: query
  parameter_name: appApiKey
  description: >-
    The same project API key accepted as a URL query parameter on at least two
    published operations — GET /user_log_event/{projectId}/{userId} and
    DELETE /{projectId}/delete_media_files. Appgain publishes these forms itself; a
    credential in the query string is logged by proxies, gateways and browser
    history, so header placement should be preferred where both are accepted.
  sources: [postman/appgain-omnichannel.postman_collection.json]
- name: parseApplicationId
  type: apiKey
  in: header
  parameter_name: x-parse-application-id
  description: >-
    Parse Server application identifier. Required, together with the master key,
    on the two Parse cloud-function operations in the published collection
    (/functions/getUserInfo, /functions/logPurchase) against the per-account
    Appbackend server URL. Appgain's backend is built on the open-source Parse
    Server stack.
  sources: [postman/appgain-omnichannel.postman_collection.json]
- name: parseMasterKey
  type: apiKey
  in: header
  parameter_name: x-parse-master-key
  description: >-
    Parse Server MASTER key. This is an unrestricted, full-privilege credential that
    bypasses Parse class-level permissions and ACLs — it is not an equivalent of the
    scoped project API key. Appgain's own published examples send it directly from
    the integration client, which means the documented path for logging a purchase
    or reading a user profile requires holding an admin-grade secret in the caller.
  risk: high
  sources: [postman/appgain-omnichannel.postman_collection.json]
- name: whatsappAuthorization
  type: http
  scheme: bearer
  bearer_format: JWT
  parameter_name: Authorization
  description: >-
    A vendor JWT carried IN ADDITION to appapikey on the WhatsApp Business API paths
    (POST /{projectId}/create_whatsapp_template and WHATSAPP sends). The token
    payload seen in Appgain's own n8n guide carries user_id, username, customer_id,
    send_message and reseller claims. It is not issued by any documented Appgain
    token endpoint; the docs do not say how an integrator obtains or refreshes it.
  sources: ['https://docs.appgain.io/integrations/n8n-integration/']
- name: whatsappAuthToken
  type: apiKey
  in: header
  parameter_name: authToken
  description: >-
    A second JWT header sent alongside Authorization on the WhatsApp template-creation
    call. Its issuance and lifetime are undocumented.
  sources: ['https://docs.appgain.io/integrations/n8n-integration/']
path_scoping:
  parameter: projectId
  location: path
  description: >-
    Tenancy is expressed in the path, not in the credential. Every operation is
    scoped by a projectId that the caller supplies; the API key is bound to that
    project.
  examples:
  - https://notify.appgain.io/{projectId}/send
  - https://automator.appgain.io/automessages/{projectId}/firevent/{trigger}/{userId}
  - https://{account_subdomain}.appgain.io/apps/{projectId}/smartlinks
credentials_source: Appgain dashboard -> Project Settings -> API and SDK Keys
rotation:
  documented: false
  notes: No key-rotation, key-expiry or multi-key policy is published.
failure_behaviour:
  method: probed
  probed: '2026-08-13'
  observations:
  - host: automator.appgain.io
    request: GET /automessages/{projectId}/firevent/{trigger}/{userId} with an invalid appApiKey
    status: 401
    body: '{"status": "failed", "message": "Not Authorized Api Key"}'
  - host: api.appgain.io
    request: GET /user_log_event/{projectId}/{userId}?appApiKey=<invalid>
    status: 401
    body: '{"status": "failed", "message": "app API key or user authentication required"}'
  - host: notify.appgain.io
    request: POST /{projectId}/send with an invalid appapikey
    status: 500
    body: '{"exception": "''NoneType'' object has no attribute ''api_key''", "message": "something went wrong", "status": "Failed"}'
    note: >-
      The send endpoint does not return 401 for a bad credential. It returns HTTP 500
      and echoes a server-side Python AttributeError back to the caller. An agent
      cannot distinguish "your key is wrong" from "the service is broken" on the
      single most important endpoint in the API.

Work with this as data

Every security artifact here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for security posture

4 MCP tools reach this
  • find_securityBrowse and filter every security artifact in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This security artifact
curl "https://apis.io/api/v1/security/appgain-authentication"
All security posture
curl "https://apis.io/api/v1/security?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.