Référence de l’API développeur WeProfit

Authentification et première requête

L’URL de base de l’API est https://api.weprofit.com/v1/dev. Créez un jeton d’accès personnel dans la carte « Jetons API » de la page Développeur. Envoyez-le dans l’en-tête Authorization sous forme de jeton Bearer. Conservez le jeton dans l’environnement de votre serveur, jamais dans le JavaScript de votre vitrine ni dans un dépôt public.

Le jeton hérite des autorisations de boutique de son propriétaire. Les membres de l’équipe ont besoin de l’accès développeur et de l’autorisation correspondante (Analyses ou Événements et commandes). Les jetons révoqués ou expirés sont refusés.

curl https://api.weprofit.com/v1/dev/stores \
  -H "Authorization: Bearer $WEPROFIT_API_TOKEN"

Choisissez une boutique dans la réponse

Utilisez un ID renvoyé par l’endpoint des boutiques pour les requêtes suivantes. Les valeurs ci-dessous sont illustratives et ne contiennent aucune donnée client.

{
  "items": [{
    "id": "STORE_ID",
    "name": "Example store",
    "platform": "shopify",
    "currency": "USD",
    "timezone": "America/New_York",
    "role": "owner"
  }]
}

Endpoints de reporting

Tous les chemins ci-dessous sont relatifs à la base de l’API et nécessitent une authentification Bearer. Remplacez :storeId par l’ID d’une boutique active accessible. Le tableau couvre les lectures de reporting. L’API REST permet aussi de mettre à jour les dépenses publicitaires et de gérer les abonnements aux webhooks ; ce n’est donc pas une API entièrement en lecture seule.

Dates, filtres et pagination

Indiquez from et to sous forme de dates UTC incluses, au format YYYY-MM-DD. S’ils sont omis, la période couvre par défaut aujourd’hui et les six jours précédents. Définissez explicitement les deux dates pour des comparaisons reproductibles. L’endpoint ad-spend utilise plutôt month et prend par défaut le mois UTC en cours.

Les listes de commandes et d’événements renvoient 50 lignes par défaut, et vous pouvez en demander jusqu’à 200. Les résultats les plus récents viennent en premier. Transmettez le nextCursor renvoyé, sans le modifier, pour obtenir une autre page. Les données peuvent changer pendant la pagination : vous n’obtenez donc pas un instantané figé.

• Les filtres de commandes comprennent order_id, status, financial_status, tracked, link_method, link_confidence, channel, currency, min_total, max_total et sent_to.
• Les filtres d’événements comprennent event_name, event_id, source, channel, country, url_contains, consent_state, currency, min_value et max_value.
• Les deux listes acceptent visitor_id et session_id. Les filtres d’événements acceptent aussi checkout_token et cart_token.

curl "https://api.weprofit.com/v1/dev/stores/STORE_ID/profit?from=2026-09-01&to=2026-09-07" \
  -H "Authorization: Bearer $WEPROFIT_API_TOKEN"

Lire plusieurs boutiques en une seule requête

GET /summary, /orders, /events, /profit et /profit/timeseries acceptent un paramètre de requête stores obligatoire, contenant jusqu’à 50 ID de boutiques séparés par des virgules. Fournissez les mêmes options de dates et de filtres que pour la requête équivalente sur une seule boutique.

Les réponses groupées contiennent des résultats avec une entrée de succès ou d’erreur indépendante pour chaque boutique. Une boutique refusée n’invalide pas les autres. Pour summary, orders et events, les succès placent leur contenu sous data ; pour profit, les succès exposent leurs champs de bénéfice à côté de storeId et ok. Le résultat de commandes ou d’événements de chaque boutique a son propre nextCursor.

Interprétez correctement les champs de bénéfice

Les rapports de rentabilité utilisent des coûts enregistrés et des coûts estimés. Les commandes annulées sont exclues du calcul du bénéfice et présentées séparément. La marge vaut null lorsque le chiffre d’affaires net est nul.

Timeseries renvoie les jours qui ont une activité de commandes ou de dépenses publicitaires, pas un calendrier complété par des zéros. Son netProfit inclut les remboursements, même si chaque élément de la série ne présente pas de champ refunds distinct. Utilisez l’endpoint profit agrégé lorsque vous avez besoin du total explicite des remboursements.

• Définitions du bénéfice et coûts inclus
• Exemple chiffré ROAS et POAS

Limites de requêtes et erreurs courantes

Les limites actuelles sont de 240 requêtes par minute et de 20 000 requêtes par jour et par jeton. En cas de limitation, réduisez la fréquence des requêtes et limitez le nombre de nouvelles tentatives. Évitez de relancer des requêtes refusées pour identifiants ou autorisations invalides sans corriger la cause.