BETA-Phase Domainreselling-API gestartet

  • Guten Morgen,



    Domainreseller können ab sofort über ein API Domains bei uns registrieren / transferieren / inhaberwechseln / löschen und Handles anlegen und editieren. Das API zur Domainregistrierung und Handleverwaltung für unsere Reseller befindet sich ab sofort in der öffentlichen BETA-Phase. Das API unterstützt sowohl SOAP als auch JSON-basiertes REST. Wir empfehlen für den Einsatz SOAP zu nutzen, da Eingaben so direkten im Client validiert werden können. Für SOAP bieten wir auch einen fertigen Client an, der in PHP geschrieben ist. Download PHP-Client: https://ccp.netcup.net/run/webservice/servers/endpoint.php


    Um Reseller von Domains bei uns zu werden, müssen Sie ein Gewerbe angemeldet haben und mindestens 10 Domains über uns beziehen. Unser Support berät Sie gerne zu den Möglichkeiten eines Domainresellings.


    Die Authentifizierung geschieht über ein Passwort und API-Key. Je Applikation kann ein individueller API-Key im CCP generiert werden. Das CCP bietet darüber ein umfangreiches Logging-System und die Möglichkeit alle via API gemachten Angaben, über eine grafische Oberfläche zu bearbeiten.


    Weitere Details zu unserem Domainreselling-API finden Sie in unserem Wiki: https://www.netcup-wiki.de/wiki/Domainreselling_API


    Als nächstes folgen individuelle Preislisten. Reseller die viele Domains bei uns abnehmen, können dann von guten Rabatten profitieren.


    Wir freuen uns über Feedback hier im Forum.


    Vielen Dank!



    Mit freundlichen Grüßen


    Felix Preuß

  • Falls Sie Unterstützung bei der Inbetriebnahme brauchen, schreiben Sie gerne hier. Sie können Zeit sparen und wir Verbesserungen für unsere Dokumentation finden.


    Wo klemmt es bei der Inbetriebnahme?

    Welche Informationen fehlen?


    Vielleicht haben wir ein paar Tipps auf Lager. :-) 

  • Guten Tag,



    das API ist für Reseller gedacht, die viele Domains verwalten wollen. Diese haben in der Regel eigene Nameserver. Zur Not bieten wir ja fertige Images für Nameserver an, die auf Root-Servern / VPS von uns einfach installiert und konfiguriert werden können. Diese Nameserver haben wiederum ein eigenes API.


    Aus dem Grund werden wir für das CCP zeitnah kein API für DNS bereitstellen.



    Mit freundlichen Grüßen


    Felix Preuß

  • Aus dem Grund werden wir für das CCP zeitnah kein API für DNS bereitstellen.

    Die Gründe sind durchaus nachvollziehbar und der Entwicklungsaufwand wird groß genug sein. Ich könnte mir vorstellen, dass vor allem die Validierung der gesendeten Daten aufwendig ist. Habt ihr darüber Nachgedacht nur eine API für ACME DNS Challenges zu machen? (also sowas wie DNS API Light mit nur TXT Records)

    Gefühlt könnte man damit die meisten "kleineren" /nicht Reseller Kunden schon glücklich machen, wenn man durch das Forum ließt. Das Interesse an Wildcardzertifikaten scheint ja durchaus da zu sein oder wenn nicht extra ein Webserver (auf 80/443) für die ACME Challenge laufen müsste.
    Ich hoffe diese Einschätzung wird nicht zu sehr von meinen eigenen Interessen beeinflusst :-)


    Viele Grüße

    Moritz

  • Habt ihr darüber Nachgedacht nur eine API für ACME DNS Challenges zu machen? (also sowas wie DNS API Light mit nur TXT Records)

    Wie soll das funktionieren?


    DNS-Einträge abseits eines Nameservers sind nicht möglich.


    Und wenn netcup nur dafür einen Nameserver zur Verfügung stellt, nutzt dir die Domain nichts mehr, da sie keinen A/MX/AAAA Record besitzen würde in dem vorgeschlagenem Modell. Dadurch kein Aufschalten auf einen Server oder Dienst, also auch kein Nutzen für das Zertifikat.

  • Er meinte wohl, dass man nur die TXT-Records für "_acme-challenge" über eine API ändern kann.

    Ja genau. Ich hatte [netcup] Felix so verstanden, dass viele "PowerUser" eh eigene DNS Server haben und deswegen vermutlich der Entwicklungsaufwand einer DNS API in keiner Relation zur Nachfrage steht. Deswegen war die Idee den Entwicklungsaufwand zu reduzieren indem man nur TXT Records über die API setzten kann. Für die ACME Challenge würde ja sogar in der Tat reichen nur den Wert für "_acme-challenge" setzten zu können. Eventuell sieht dafür das Verhältnis Entwicklungsaufwand / Nachfrage besser aus :-) Das kann aber ja aber natürlich nur netcup selbst beurteilen ob diese Idee Sinn macht.

  • Die Fehlermeldung "Array is empty" bei Server-REQ-Id 4hUgJVG1jXa20=25AXZ9bO= ist nicht hilfreich. Dabei bemerkte ich weiterhin, dass hier meine gesetzte Client-Request-ID nicht im Log auftaucht.

    Der gesendete Request (via von Netcup generiertem PHP-API-Client) lautet (anonymisiert):


    Es ist auch egal, ob ich die createHandle mit null oder [] als Parameter für optionalhandleattributes aufrufe.


    So sieht dieser Request / Response im CCP aus:

    Bildschirmfoto 2017-12-05 um 16.03.31.png

  • Hallo Hecke29,


    das freut mich sehr, dass Sie nun unsere API testen. Ich prüfe Ihre Meldungen und gebe Ihnen hier wieder Bescheid.


    Hier schon mal die ersten Antworten:

    * Descriptions von updateHandle und createHandle sind jetzt an der richtigen Stelle

    * createHandle bietet keinen Dubletten-Check, sie sehen Ihre Handles mit listallHandle auf der API oder in Ihrem CCP.

    * Sie können jetzt sowohl mit NULL, als auch mit einem leeren Array die optionalen Attribute bei den Handles belegen.

  • Was mir bislang aufgefallen ist:

    • Es gibt keine Möglichkeit, mir alle Domains auflisten zu lassen? Wieso? Oder habe ich etwas übersehen?
    • Der Sinn von dem poll-System ist mir nicht ganz klar. Ich dachte, darüber kann ich das Ergebnis asynchroner Anfragen abrufen. Allerdings erhalte ich darüber auch meine komplette History an API-Calls, sofern ich nicht nach jedem Request diesen im poll()-Array suche und als gelesen markiere. Was zur Folge hat, dass die Hälfte aller API-Calls ackpoll()s sind.
      So wie ich das verstehe erhalte ich für jeden API-Call eine direkte Rückmeldung und ggf. später noch eine (z.B. "transfer successful"). Die API interessiert beim poll() aber eigentlich nur die zweite, bei synchronen Antworten kenne ich die Rückmeldung doch schon. Zwischen diesen Nachrichten zu filtern dürfte mühsam und fehleranfällig sein. Und kann ich über dieses System auch z.B. über ausgehende Transfers informiert werden? Diesen würde ja keine Anfrage seitens der API vorausgehen.
    • Mein Testsystem hat teilweise fälschlicherweise bei logout() das API-Passwort statt der Session-ID übermittelt. Dennoch war der Logout erfolgreich. Ich vermute einen Fehler?
    • Wenn ich keine Handles angelegt habe erhalte ich bei listallHandle() über SOAP den Fehler SoapFault: 5012 ohne weitere Informationen. Auch das CCP meldet lediglich "Getting information about handles failed". Hier wäre eine Fehlermeldung wie üblich über messagestatus = error etc. besser. Dasselbe beim Anlegen von Handles: Wenn ich die Telefonnummer vergesse erhalte ich eine entsprechende Fehlermeldung, gebe ich keinen Namen an (z.B. um eine Firma einzutragen) erhalte ich eine nichtssagende Nummer (ich glaube 5016).
    • listallHandle() liefert ein zweidimensionales Array in responsedata (sprich $responsedata[][0] ist die ID und $responsedata[][1] ist der Name). Ist okay, allerdings würde ich konsequenterweise (und auch der Übersicht halber) ein Objekt ([{ id: 123, name: "Ringelnatz" }] ausliefern.
    • Der abgefragte Inhalt befindet sich manchmal in responsedata und manchmal in responsedata. Idealerweise wäre das einheitlich.
  • Hallo Ringelnatz,


    vielen Dank für Ihre Rückmeldungen.

    * Eine Funktion listDomains war bislang nicht vorgesehen.

    * Korrekt, der Poll enthält momentan alle Nachrichten (außer poll und ackpoll commands)

    ** Asynchrone Jobs sind auf der API die Seltenheit, auch .de Domains werden hier ohne Verzögerung eingerichtet.

    * In dem Soap Error Objekt sind sowohl die Fehlernummer als auch die Fehlermeldung enthalten.

    * responsedata wird für komplexe Inhalte verwendet.

    * Im Resonse beim Logout sehe ich nur die Server Request ID. Die sieht ein bisschen aus wie ein Passwort. Sollte ich mich irren, schreiben sie mir bitte gerne eine Mail an mail@netcup.de mit Informationen zu dem Request.

    * Die Array Formatierung bei listHandels wird wahrscheinlich überarbeitet. Kann noch nicht sagen wann es live gehen wird, möglicherweise erst nächste Woche.

  • * Eine Funktion listDomains war bislang nicht vorgesehen.

    Naheliegenderweise wäre eine solche Funktion praktisch. Die Liste sollte selbst für größere Reseller nicht viel länger sein als die von listallHandle() (und definitiv kleiner als die Rückgabe von poll() nach kurzer Zeit, sofern ich nicht jeden Call direkt quittiere).

    Wenn solch eine Funktion nicht kommt ist das auch kein Problem, dann lege ich meinen Domainbestand selbst in einer Datenbank ab. Dann ist aber wichtig: Wie erhalte ich Informationen über ausgehende Transfers (per AuthCode), ob der Domaininhaber die Löschung/den Inhaberwechsel bestätigt hat etc.? Denn irgendwie muss ich meine lokale Datenbank ja synchron halten.

    ** Asynchrone Jobs sind auf der API die Seltenheit, auch .de Domains werden hier ohne Verzögerung eingerichtet.

    Hierzu wären Informationen nicht schlecht, unter welchen Umständen das dennoch passiert.

    * In dem Soap Error Objekt sind sowohl die Fehlernummer als auch die Fehlermeldung enthalten.

    In den beschriebenen Fällen habe ich tatsächlich nicht mehr erhalten als (sinngemäß, habe nur noch die Logdatei)

    Zitat

    {"exception":"[object] (SoapFault(code: 0): 5016 at /app/Classes/DomainWebserviceSoapClient.php:35)

    [stacktrace]

    #0 /app/Classes/DomainWebserviceSoapClient.php(35): SoapClient->__soapCall('createHandle', Array)

    #1 /app/Classes/DomainWebserviceSoapClient.php(293): App\\Classes\\DomainWebserviceSoapClient::_Call('createHandle', Array)

    [...]

    Eine Fehlermeldung gab es nicht, weshalb ich einen Fehler vermute.

  • Hallo Ringelnatz,


    Information über Löschung/den Inhaberwechsel Bestätigung erhalten sie per poll über den entsprechenden Auftrag.


    Wir prüfen eine Umsetzung der listDomains Funktion.


    Es hängt von der Registry ab, ob Jobs direkt oder nicht ausgeführt werden. Das lässt sich pauschal nicht sagen. Bei z.B. .cn Domains erfolgt bei uns die Registrierung nicht in Echtzeit. Die populären Domains werden in Echtzeit ausgeführt.


    Versuchen Sie mal mit try/catch den Soap Fehler zu fangen. Sehen Sie sich das Exception object an. Darin müssten Sie auch eine Fehlermeldung sehen.