Intégration du trading de secondes
Intégration du trading de secondes: Intégration Agent Java SDK v0.3.0, exemples, paramètres et sémantique de réponse.
Ce guide cible Agent Java SDK v0.3.0 et Java 8+.
Préparer l’identité, l’authentification et les fonds
Le trading en secondes utilise la même liaison utilisateur et la même authentification d’entrée que le trading perpétuel. Il utilise les soldes de financement ; la marge perpétuelle utilise les soldes des contrats. Configurez séparément le produit/mode frontend et l’environnement des fonds backend.
Initialisez client en utilisant Démarrage rapide. Enregistrez le mappage utilisateur lié et obtenez l’ID utilisateur partenaire de la session backend authentifiée.
Rediriger l’entrée
Le SDK appelle POST /v1/agent/create-entry-url. Renvoyez webUrl à l’interface du partenaire et ouvrez-le immédiatement. expireAt utilise les secondes Unix. Un ticket est de courte durée et unique ; en obtenir un autre après péremption ou consommation.
Utilisez les routes frontales réelles fournies par 6MM. redirectPath est un chemin de plateforme relatif commençant par / ; returnUrl est un partenaire absolu HTTP/HTTPS URL. Un ticket d’entrée authentifie l’utilisateur et n’exécute pas de transfert.
Entrée intégrée
Utilisez les flux partner-token et tokenProvider existants. Il n’existe aucun jeton spécifique à la prédiction. Créez le widget avec les page et tradingMode souhaités, et utilisez son channelId actuel lors de l’appel du backend partenaire.
Le SDK appelle POST /v1/agent/create-embed-token. symbol est facultatif ; il ne choisit pas un produit de seconde zone. La sélection de produits appartient au frontend. Le jeton ne sélectionne pas un environnement de fonds et ne modifie pas les soldes.
Exemple d’interface complet
Ces options ont été vérifiées par rapport au runtime public Trading Widget 1.8.0 le 10/10/2026. Les versions Widget et Agent Java SDK sont indépendantes.
Réponse backend du partenaire
/api/seconds/embed-token est un point de terminaison appartenant à un partenaire, et non un nouveau 6MM API. Authentifiez la session, dérivez agentUserId côté serveur et appelez createEmbedToken. Renvoyez cette structure de niveau supérieur :
Utilisez la valeur réelle expireAt de la réponse de l’agent, et non la valeur illustrative. La réponse de l’agent ne contient pas channelId ; votre backend fait écho à la valeur de la requête actuelle. Si votre API encapsule les résultats dans data, déballez ce calque avant de revenir de tokenProvider. Rejetez les échecs commerciaux plutôt que de renvoyer un objet de réussite non valide.
Chaque initialisation ou renouvellement obtient un nouveau jeton. Ne cachez et n’échangez plus jamais le même jeton, ni ne le placez dans un URL. Réutilisez le même canal d’instance lors du renouvellement ; utilisez le nouveau canal après avoir recréé l’instance.
Correspondre à l’environnement des fonds
Une interface demo nécessite des demandes de fonds simulées avec environment=SIMULATED. Une interface real nécessite des fonds de production. Ni tradingMode ni la création de jetons ne modifient l’objectif des fonds backend.
Lorsque vous changez d’utilisateur ou de mode de trading, détruisez l’ancien widget et créez une nouvelle instance. Recherchez les soldes de financement, transférez les fonds et confirmez le résultat final via le point de terminaison du statut spécifique au financement avant de traiter l’utilisateur comme financé.
Voir Portefeuille de financement et Guide environnement.