Enregistrer une app d’intégration
Créez l’enregistrement de l’app externe et confirmez les grant types et redirect URIs approuvés pour votre tenant.
Utilisez ce parcours pour les intégrations externes approuvées. La configuration publique commence par l’enregistrement d’app, les scopes approuvés, les tokens, les webhooks et le transport GraphQL. L’accès revu est réservé aux workflows qui nécessitent des capacités partenaires.
Commencez par le contrat public puis passez à un accès revu uniquement si votre cas d’usage le nécessite.
Créez l’enregistrement de l’app externe et confirmez les grant types et redirect URIs approuvés pour votre tenant.
Ne demandez que les scopes approuvés par l’administrateur du tenant. Ne concevez pas pour des scopes non publiés.
Utilisez authorization code lorsqu’un utilisateur agit dans le workflow, ou des service tokens pour l’automatisation headless.
Validez les JWT via JWKS et configurez webhooks ou transport GraphQL avec tenant scoping.
Utilisez le flux de demande partenaire pour APIs avancées, bundles GraphQL curés, fédération ou onboarding spécifique.
Ces surfaces publiques constituent le point de départ supporté pour les intégrateurs tiers.
Enregistrement d’app, découverte des scopes, gouvernance, émission de service tokens et rotation de secret.
Ouvrir la référence APIFlux approuvés pour accès délégué par utilisateur et automatisation machine-to-machine.
Ouvrir la référence APIGestion, tests et diagnostic des webhooks sortants pour intégrations approuvées.
Ouvrir la référence APITransport GraphQL avec bearer auth et tenant scoping, sans dump de schéma ni inventaire des opérations.
Ouvrir la référence APITraitez le contrat public comme seule frontière supportée pour l’automatisation, sauf si vous disposez d’un accès revu.
Stockez client secrets et service tokens dans votre propre gestionnaire de secrets et faites des rotations maîtrisées.
Concevez les consommateurs de webhook comme idempotents et tolérants aux retries.
Considérez que les topics lisibles par machine et les payloads d’exemple restent en anglais canonique.
# Register an external integration app
curl -X POST https://auth.knogin.com/v1/platform/apps \
-H "Authorization: Bearer <admin-access-token>" \
-H "Content-Type: application/json" \
-d '{"name":"Case sync connector","grant_types":["client_credentials"],"requested_scopes":["webhooks:write"]}'
# Exchange client credentials for a bearer token
curl -X POST https://auth.knogin.com/v1/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=<client-id>&client_secret=<client-secret>&scope=webhooks:write"
# Create an outbound webhook
curl -X POST https://auth.knogin.com/v1/webhooks \
-H "Authorization: Bearer <access-token>" \
-H "Content-Type: application/json" \
-d '{"url":"https://integrator.example/webhooks/argus","events":["case.updated"]}'L’exemple reste dans le contrat public revu: enregistrer, obtenir un token, puis créer un webhook sortant.
Ces workflows existent mais ne sont pas publiés comme blueprint public.
Les workflows de control plane étendus et les chemins administratifs partenaires ne sont partagés qu’après revue.
Des bundles approuvés peuvent être partagés pour des programmes ciblés sans exposer le schéma complet.
Fédération entreprise, SAML, revue de déploiement souverain et onboarding spécifique sont gérés au cas par cas.
Utilisez ce formulaire si vous avez besoin d’un workflow revu, d’une coordination sandbox ou d’une documentation partenaire volontairement non publiée.
Parlez-nous de vos besoins d'intégration et nous vous répondrons sous 2-3 jours ouvrables.