Feature request: custom provider #99

Closed
opened 2025-11-20 04:20:14 -05:00 by saavagebueno · 3 comments
Owner

Originally created by @fredericrous on GitHub (Feb 7, 2021).

Originally assigned to: @qdm12 on GitHub.

  1. What's the feature?

Give users the ability to configure a custom provider. Looking at the current list of providers, I see a lot of providers are essentially calling one URL with a get request. We could give users the ability to define a url

{
    "settings": [
        {
            "provider": "custom",
            "domain": "example.com",
            "url": "https://someddns.service/update?domain=mondomain.fr&monToken=token&monIP",
            "displayName": "SomeDDNS"
        }
    ]
}
  1. Extra information?

We could go further by letting the user define a return code or to let him define HTTP headers, however in most cases the response seems to be 200 and no extra header is needed

The cons I see of implementing this is that we won't know which provider users are using (without some kind of anonymous analytics on which user could opt out)
The pros: less providers to implement, more providers supported by just documenting how to set them up

Originally created by @fredericrous on GitHub (Feb 7, 2021). Originally assigned to: @qdm12 on GitHub. 1. What's the feature? Give users the ability to configure a custom provider. Looking at the current list of providers, I see a lot of providers are essentially calling one URL with a get request. We could give users the ability to define a url ``` { "settings": [ { "provider": "custom", "domain": "example.com", "url": "https://someddns.service/update?domain=mondomain.fr&monToken=token&monIP", "displayName": "SomeDDNS" } ] } ``` 2. Extra information? We could go further by letting the user define a return code or to let him define HTTP headers, however in most cases the response seems to be 200 and no extra header is needed The cons I see of implementing this is that we won't know which provider users are using (without some kind of anonymous analytics on which user could opt out) The pros: less providers to implement, more providers supported by just documenting how to set them up
Author
Owner

@fredericrous commented on GitHub (Feb 7, 2021):

That's just a suggestion. As I'm using wildcard records with gandi and ovh I don't use this kind of paradigm. But I think that it could reduce the amount of code to maintain. And writing doc is sure less fun than coding but way faster ^^

@fredericrous commented on GitHub (Feb 7, 2021): That's just a suggestion. As I'm using wildcard records with gandi and ovh I don't use this kind of paradigm. But I think that it could reduce the amount of code to maintain. And writing doc is sure less fun than coding but way faster ^^
Author
Owner

@qdm12 commented on GitHub (Feb 7, 2021):

A few of them use the dyndns protocol with tiny variations. We could tackle that 👍

But otherwise, it's highly variable between each provider and not just a GET request.

@qdm12 commented on GitHub (Feb 7, 2021): A few of them use the dyndns protocol with tiny variations. We could tackle that 👍 But otherwise, it's highly variable between each provider and not just a GET request.
Author
Owner

@qdm12 commented on GitHub (Jan 19, 2024):

Done in 0c561d4378

Documentation is at https://github.com/qdm12/ddns-updater/blob/master/docs/custom.md

It's sort of simple for now, but could be extended to some extent until implementing the provider specific code in Go would be simpler.

@qdm12 commented on GitHub (Jan 19, 2024): Done in 0c561d437816022383a89076850e10642ca142a9 Documentation is at https://github.com/qdm12/ddns-updater/blob/master/docs/custom.md It's sort of simple for now, but could be extended to some extent until implementing the provider specific code in Go would be simpler.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ddns-updater#99