Vérifier et accorder l'accès à un abonnement depuis votre backend

De votre backend, utilisez l’API côté serveur d’Adapty pour vérifier si un utilisateur a un abonnement actif et pour accorder un accès manuellement. Ce guide couvre les deux appels les plus courants — getProfile et grantAccessLevel — et montre comment demander à un agent de codage IA d’écrire l’intégration pour votre stack.

Avant de commencer

• Une clé API secrète : Retrouvez-la dans App settings → General, dans le champ Secret key. Les clés sont spécifiques à chaque application. Stockez-la dans une variable d’environnement (par exemple, ADAPTY_SECRET_KEY) et envoyez-la sous la forme Authorization: Api-Key {key}.
• L’URL de base : Toutes les requêtes sont envoyées à https://api.adapty.io.
• Un moyen d’identifier l’utilisateur : Envoyez soit adapty-customer-user-id (votre propre identifiant utilisateur — fonctionne uniquement si vous identifiez les utilisateurs dans l’application) ou adapty-profile-id (l’identifiant de profil Adapty). Ils sont interchangeables ; utilisez l’un ou l’autre.

Vérifier un abonnement

Pour vérifier l’état, appelez getProfile avec GET et transmettez l’identifiant utilisateur dans un en-tête — il n’y a pas de corps de requête.

const res = await fetch("https://api.adapty.io/api/v2/server-side-api/profile/", {
  headers: {
    "Authorization": `Api-Key ${process.env.ADAPTY_SECRET_KEY}`,
    "adapty-customer-user-id": userId,
  },
});
const { data } = await res.json();

function hasActiveAccess(profile, accessLevelId = "premium") {
  const level = profile.access_levels?.find(a => a.access_level_id === accessLevelId);
  if (!level) return false;
  if (level.is_in_grace_period) return true;
  if (!level.expires_at) return true;             // lifetime / non-expiring
  return new Date(level.expires_at) > new Date(); // not expired yet
}

if (hasActiveAccess(data)) {
  // unlock premium features
}

Contrairement au profil SDK, la réponse côté serveur ne contient pas de champ is_active. Déduisez vous-même le statut à partir de access_levels[].expires_at : null signifie accès à vie, une date future signifie actif, et une date passée signifie expiré. Traitez is_in_grace_period comme toujours actif. Pour l’ensemble des champs du profil et du niveau d’accès, consultez getProfile.

Accorder l’accès manuellement

Pour débloquer des fonctionnalités payantes sans achat — codes promo, accès investisseur ou bêta, cas de support — appelez grantAccessLevel avec POST.

await fetch("https://api.adapty.io/api/v2/server-side-api/purchase/profile/grant/access-level/", {
  method: "POST",
  headers: {
    "Authorization": `Api-Key ${process.env.ADAPTY_SECRET_KEY}`,
    "adapty-customer-user-id": userId,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ access_level_id: "premium" }), // add "expires_at" for temporary access
});

• Le niveau d’accès doit déjà exister dans votre tableau de bord (Access levels) — access_level_id est son identifiant, pas un nouveau nom.
• Les attributions manuelles n’apparaissent pas dans les analyses. Elles sont uniquement transmises à votre intégration webhook et à l’Event Feed, donc les graphiques de revenus et de conversion ne les reflètent pas.

Pour les détails de la requête et de la réponse, consultez grantAccessLevel.

Construisez-le avec votre agent de codage IA

Donnez à votre agent de codage IA ce guide et la spécification API en Markdown (ajoutez .md à n’importe quelle URL de page), indiquez-lui votre stack, et laissez-le écrire les appels :

• Spécification OpenAPI
• getProfile
• grantAccessLevel

Exemple de prompt :

Using the Adapty server-side API spec, write backend functions to check whether a
user has an active "premium" access level (GET /profile/, derive status from
expires_at — there's no is_active field) and to grant it (grantAccessLevel).
Authenticate with ADAPTY_SECRET_KEY and identify users by adapty-customer-user-id.

The agent writes the code, but it can’t run your backend or set your keys — you provide the secret key and the user identifiers.

Limites

• Limite de débit : Appliquée par clé API et assignée par application, donc aucun chiffre universel ne s’applique — consultez Limites de débit. Il s’agit d’un débit soutenu plutôt que d’un quota par minute, et certains endpoints sont limités plus bas : createVirtualCurrencyTransaction autorise 600 requêtes par minute par application par défaut. Indiquez à votre agent de réessayer avec un backoff sur 429 et de respecter Retry-After lorsqu’il est présent.
• Clés spécifiques à chaque application : Chaque clé fonctionne pour une seule application ; utilisez la clé correspondante pour chaque application.
• Un identifiant requis : Chaque requête nécessite adapty-customer-user-id ou adapty-profile-id.