Projects & API keys
A project is the container everything in e-sat.ly hangs off. Every short link belongs to exactly one project, and the project is what decides:
- Who the links belong to — projects sit inside your organization, and nothing is ever visible across organizations.
- How long the data is kept — each project has its own data-retention window.
- How links get created — each project has one API key, and that key is what your systems use.
You'll find them under Configuration → Projects.
How many projects should you have?
Most organizations need only a few. A project is worth creating when a set of links needs to be counted, reported on, or kept for a different length of time than the rest — one per brand, per market, or per major integration is a common shape.
Don't create a project per campaign. Links are already filterable by date and searchable by destination, and a link can't be moved between projects afterwards, so a sprawl of projects is harder to undo than to avoid.
Creating and editing a project
Open Projects
Go to Configuration → Projects in the console.
Create the project
Give it a title you'll recognize later. This is the name you'll see in the project filter on every other screen.
Set the data-retention window
Use the retention slider to choose how long this project's links and click data are kept — from 6 months to 2 years. New projects start at 2 years, the maximum. Read Data retention before lowering it.
Copy the API key
The project's key is on the same screen. Copy it into whatever system will be creating links. See the API reference.
Each project row also has a View links action, which opens Short Links already filtered to that project.
Why there's no link count on this screen
Projects don't show how many links they hold, because counting them across tens of millions of rows would make the screen slow every time you opened it. For volume figures, use Usage — that's the screen built for the question.
API keys
Each project has one API key. It's a long random value that acts as both the password and the address: the key identifies the project and the organization it belongs to, so your API calls never need to send an organization or project id. You just send the key and the URL you want shortened.
Anything created with that key lands in that project, inherits that project's retention window, and shows up in that project's analytics.
Treat the key like a password
Anyone holding a project's key can create links in your project and list the links already in it. Keep it in your application's secret store or environment configuration — never in front-end code, a public repository, or a support ticket.
Re-issuing a key
The project screen lets you re-issue the key, which replaces it with a new value.
Re-issuing takes effect immediately
The moment you re-issue, the old key stops working. Any system still using it will start failing with an authentication error until you give it the new value. Plan the swap before you click — re-issue, then update every system that holds the key.
Re-issue straight away if a key has been shared by mistake, committed to a repository, or exposed in a log. Existing links are unaffected: they keep resolving normally, and their click history is untouched.
Which key does the suite use?
The SMS and Viber shortening the suite does for you is already wired up — you don't need to configure a key for it. The keys on this screen are for your own systems calling the API directly. If you want to point the suite at a different shortener entirely, that's a separate setting under URL shorteners.