Démarrage rapide

Préparez un compte ShortsMonkey et un terminal côté serveur avec un accès HTTPS. L'exemple cURL nécessite cURL ; JavaScript a besoin de Node.js avec fetch ; Python a besoin de requêtes. Toutes les clés affichées sont des espaces réservés : utilisez une clé de votre propre compte.

Connectez-vous, ouvrez la console API et copiez la clé complète de la révélation unique. Les requêtes REST nécessitent api:read; Les outils MCP nécessitent mcp:read. Sélectionnez les deux pour les deux intégrations, ou uniquement l’autorisation dont votre intégration a besoin.

export SHORTSMONKEY_API_KEY="sm_live_..."

GET /v1/auth/verify, GET /v1/credits, GET /v1/credits/costs, les contrôles de santé et la gestion des clés ne consomment pas les 10 appels quotidiens de données. L’authentification et le contrôle du propriétaire restent obligatoires.

Exécutez curl -i https://api.shortsmonkey.com/v1/auth/verify -H "Authorization: Bearer $SHORTSMONKEY_API_KEY" dans votre terminal. Cette vérification REST nécessite également api:read. Attendez-vous à HTTP 200, puis confirmez que data.authenticated est vrai et que data.scopes contient api:read. Une authentification réussie ne garantit pas un classement non vide.

Exécutez l’un des exemples ci-dessous ; vous n'avez pas besoin d'exécuter les trois. La requête lit un instantané vidéo long chinois stable stocké et ne déclenche pas de récupération YouTube en direct. Vérifiez d'abord l'état du HTTP. Pour une réponse non-200, lisez error.code au lieu de traiter l’erreur JSON comme des données de classement.

data.all_data.items contient la page actuelle avant les filtres de demande ; data.filter_data.items contient la page actuelle après les filtres par défaut et les filtres de demande. L'un ou l'autre tableau peut être vide et leurs comptes peuvent différer ; un tableau vide n'est pas un échec d'authentification. Utilisez meta.snapshot_at pour évaluer l'âge des données et conservez meta.request_id pour les diagnostics.

Pour une autre page, transmettez all_data.next_cursor comme all_cursor et filter_data.next_cursor comme filter_cursor, en conservant les filtres d'origine. null termine cet ensemble de résultats ; n'échangez pas les cursor. Chaque nouvelle demande de données REST réussie utilise un appel quotidien. credits.unlimited étant vrai ne signifie pas des demandes de données illimitées ; vérifiez daily_usage.remaining.

401 INVALID_API_KEY : vérifiez la clé sm_live_ complète, l'espace après Bearer, la variable d'environnement et si la clé a expiré, a été révoquée ou a dépassé sa période de grâce de rotation. Pour 403 INSUFFICIENT_SCOPE, vérifiez api:read; pour 403 ACCOUNT_DISABLED, vérifiez l'état du compte et contactez l'assistance. Les tentatives répétées ne réparent pas l'authentification ou les autorisations.

Distinguer 429 par error.code : API_DAILY_LIMIT_REACHED nécessite d'attendre jusqu'à 00h00 Asie/Shanghai ; RATE_LIMITED nécessite de réduire la fréquence et les demandes simultanées et d'honorer Retry-After lorsqu'il est fourni. 503 DATA_STALE signifie que l'instantané stocké est trop ancien ; SERVICE_UNAVAILABLE signifie indisponibilité temporaire. Utilisez des tentatives limitées avec interruption et conservez l’ID de la demande.

Conservez la clé dans une variable d'environnement côté serveur ou dans un magasin secret et envoyez-la dans l'en-tête d'autorisation. Ne le mettez pas dans le code du navigateur, les URL, Git, les captures d'écran, les journaux ou les analyses. Partagez uniquement l'ID de demande, l'opération, l'heure, l'état et le code d'erreur pour les diagnostics. Si elle est exposée, faites pivoter ou révoquez la clé dans la console et mettez à jour la configuration de votre serveur.