Publishing
Publier une Data App (déprécié)
Sucre de publication one-shot pour apps type api : soumettre et publier. Remplacé par l’assistant d’import de contrat et la chaîne en trois étapes.
POST
Publier une Data App (déprécié)
POST https://api-datahub.octoparse.com/v1/data-apps
Authentification : clé API requise (Authorization: Bearer <API Key>).
Sucre one-shot de publication pour apps type api (déclaratives) : chaîne atomique interne créer identité → sauver workspace → créer build → créer release. Soumettre = publier.
La version est décidée par l’action de publier : par défaut on incrémente le segment patch de la version actuelle ; ou passez une version explicite à trois segments. Les builds n’ont pas de numéro de version.
Le namespace est déduit de l’auth : identity.app_name dans le manifest n’est que le nom de l’app ; l’app atterrit sous le (utilisateur, nom) de l’éditeur. app_id est émis une fois et survit aux changements de username ou de nom ; les références externes sont toujours à deux segments. Les releases sont immuables : republier ajoute une version et n’écrase jamais une ancienne. Deux portes de nom avant publish : le compte doit avoir un username (400) ; la propriété historique de (username, nom d’app) doit être la vôtre — après transfert de username, les noms du prédécesseur entrent en gel de 30 jours (409).
Requête
Corps de la requête
string
requis
Texte brut du manifest.
object
Fichiers joints.
object
Map de noms de secret vers valeurs en clair.
Exemple de requête
Réponse
200 succès
data. Champs :
string
requis
Nom de l’app.
string
Nom d’utilisateur de l’éditeur.
string
Numéro de version publiée.
string
—
object
requis
—
string[]
—
string
—
Erreurs
Les réponses d’erreur utilisent
{"error": {code, category, message, retryable}}. Voir Erreurs.