If your site does not run on GitHub, WordPress or Ghost, RankMill can still hand your posts over. You have two choices. RankMill can call a webhook you run when a post goes out. Or your own code can call the RankMill API to fetch finished posts, then confirm each one live once it is up.
This post compares the two. It covers when to pick each one, how to limit an API key to the projects you choose, and why confirming a post live matters more than it looks.
The two do-it-yourself destinations
Each project has one publish destination. Most people pick a GitHub repository, a WordPress site or a Ghost site. The webhook and the API are for everything else: a custom app, a static site your own script builds, a headless setup, or a stack RankMill has no direct connection for.
The big difference between them is who makes the call.
The webhook: RankMill calls you
With a webhook, you run an address that RankMill can reach. When a post goes out, RankMill calls it. Your code on the other end takes the post and does whatever your site needs with it.
A post goes out for the same reasons it would on any other destination:
- You pressed Publish.
- The post reached its scheduled time.
- The project publishes automatically.
The webhook is just where the post lands. RankMill still decides when, based on your buttons, your calendar and your settings.
The API: your code calls RankMill
With the API, the direction flips. RankMill does not call anything. Your own code does the work, in four steps:
- Your code lists the project's finished posts.
- It reads the post it wants to publish.
- It publishes the post on your site.
- It confirms the post live with RankMill, giving its address.
Your code decides when this happens. It could run on a timer, as part of a site build, or when someone presses a button in your own tools.
When to pick the webhook
The webhook suits you when you want RankMill to stay in charge of timing. Pick it if:
- You want your site to react the moment a post goes out.
- You already run a server that takes incoming requests.
- You like using Publish, the calendar or Auto-schedule to decide when posts appear.
Edits on a webhook
Say you fix a typo after a post has gone out. The app marks the published copy "Out of date". You can then push the change, and your webhook gets the new version as an update.
Nothing sends that update on its own. You choose when to push it. So build your handler to expect a post it has already seen to arrive again as an update, and to replace the old copy rather than add a second one.
When to pick the API
The API suits you when your own code should be in charge. Pick it if:
- Your site is built on a schedule, and you would rather pull posts in during that build.
- You would rather not run an address for RankMill to call.
- You want your code, not RankMill, to decide the exact moment a post goes live.
Edits on the API
Edits are simpler here. Posts fetched over the API need no update. Your code reads the current version of a post each time it asks for it, so the next fetch picks up your changes.
Neither one costs credits
Credits are only spent on writing a post. Publishing and sending updates are free, and so is anything you do over the API. Nothing on the API queues an agent. So you can fetch and confirm as often as your setup needs.
Scoping an API key to the projects you choose
To use the API, your team mints an API key. Keys belong to the team, not to a person. When you create one, you choose what it can reach: every project the team owns, or just the ones you pick.
Scoping is worth a minute of thought. A few habits help:
- One key per site or system. If you look after a handful of client sites, give each site's code its own key, scoped to that one project. A script for one client then cannot touch another client's posts.
- Store it straight away. The key is shown once, when you create it. Copy it into wherever your code keeps its secrets before you close the page.
- Revoke freely. You can revoke a key whenever you like. If one leaks, or a site moves on, revoke it and mint a new one if you still need access.
What a key can and cannot do
The API is small on purpose. A key can:
- List a project's finished posts.
- Read one post.
- Confirm a post live once your own code has published it.
- Replace a project's website profile, so you can keep the profile in your own repo, CMS or script and push it in.
A key cannot list projects, and it cannot read a website profile back. So your code needs to know which project it works on before it starts, since it has no way to ask for the list.
The API settings page also has a skill file you can download. Give it to your AI assistant and it can call the API for you.
Why confirming a post live matters
When your code publishes a post on your site, RankMill cannot see that happen. Confirming is how it finds out. It is a small call, but several parts of the app depend on it.
The calendar
The calendar shows what is planned and what has already been published. When your code confirms a post, it shows as published. That keeps the calendar in line with what is actually on your site, so you can plan the next few weeks with a true picture.
The Publishing tab
The project's Publishing tab lists everything the project has published or tried to, whatever the destination. Each entry shows its status, the latest error and a Retry button.
This tab matters even more for these two destinations. Publishes to a webhook or the API do not show in Activity. The Publishing tab is where you look to see what went out and what went wrong.
Needs attention
Needs attention lists finished posts that are not published and not on their way out. Once a post is confirmed as published, it stops waiting on you there. Your list stays short and only holds the things that really need you.
Internal links in later posts
The writer links each new post to relevant ones the project has already published, from the most recent fifty. To do that, it needs to know where each published post lives.
When your code confirms a post with its address, RankMill has that address. Later posts can then link to it. If you do not send the address, you can give the project a URL pattern instead: an https address with the slug in the path. Posts already written keep the links they have.
If you forget to confirm
If a post went live without a confirm, you can mark it as published in the app. If you got it wrong, you can move it back. It is still worth building the confirm into your code, so nobody has to remember.
Choosing between them
A quick way to decide:
- You want RankMill to push posts the moment they go out: use the webhook. Push edits as updates when you are ready.
- You want your own code to pull posts when it suits you: use the API. Scope a key to the project, fetch the post, publish it, then confirm it live with its address.
Either way, your posts end up on your own site, and you stay in charge of what goes out.