Managing API Keys for Development, Staging, and Production

Create and manage multiple Township Canada API keys for different environments. Naming conventions, key rotation, environment variables, and CI/CD setup.

Most API integrations span multiple environments—local development, a staging server, and production. Using a single API key across all three creates problems: one accidental revocation takes everything down, you can't track which environment is generating traffic, and debugging becomes harder when all requests look identical in the logs.

Township Canada lets you create unlimited API keys on paid plans. The recommended approach is one key per environment, per project.

Creating API keys

API keys are managed from the Developer Portal. To create a new key:

  1. Go to API in the main navigation
  2. Click + Add Key
  3. Enter a descriptive name (see naming conventions below)
  4. Click Create
  5. Copy the key immediately — it will not be shown again

Each key displays its name, creation date, and last-used timestamp. Keys can be revoked individually without affecting any other key on your account.

Copy your key before closing the dialog. Township Canada does not store the full key value after creation. If you lose it, revoke the key and create a new one.

Naming conventions

A consistent naming pattern makes it easy to identify keys at a glance, especially once you have several. Use the format:

{Environment} — {Project} {Version}

Examples:

Key nameWhat it's for
Production — Well Mapper v2Live production traffic for version 2 of your app
Staging — Well Mapper v2Pre-release testing against real data
Dev — Local TestingYour local development environment
CI — Well MapperAutomated tests in your CI pipeline
Dev — Jane SmithA team member's personal development key

Avoid generic names like "API Key 1" or "Test Key". When you're reviewing keys six months from now, a descriptive name tells you exactly what to keep and what to revoke.

Environment variable setup

Never hardcode an API key in your source code. Use environment variables so keys stay out of version control.

Node.js

Create a .env file in your project root:

TOWNSHIP_CANADA_API_KEY=tc_live_your_key_here

Load and use it in your application:

// Make sure dotenv is loaded early (e.g., in your entry file)
require("dotenv").config();

const response = await fetch(
  "https://developer.townshipcanada.com/search/legal-location?location=NW-36-42-3-W5",
  {
    headers: {
      "X-API-Key": process.env.TOWNSHIP_CANADA_API_KEY
    }
  }
);

For the Maps API tiles, pass the key as a query parameter instead:

const tileUrl = `https://maps.townshipcanada.com/grid/dls/twp/{z}/{x}/{y}.mvt?api_key=${process.env.TOWNSHIP_CANADA_API_KEY}`;

Python

Create a .env file:

TOWNSHIP_CANADA_API_KEY=tc_live_your_key_here

Load it using python-dotenv:

import os
from dotenv import load_dotenv
import requests

load_dotenv()

api_key = os.environ.get('TOWNSHIP_CANADA_API_KEY')

response = requests.get(
    'https://developer.townshipcanada.com/search/legal-location',
    headers={'X-API-Key': api_key},
    params={'location': '10-15-23-4-W4'}
)

Keeping keys out of git

Add .env to your .gitignore file:

# .gitignore
.env
.env.local
.env.*.local

Commit a .env.example file with placeholder values instead. Other developers on your team know what variables to set without seeing real credentials:

# .env.example
TOWNSHIP_CANADA_API_KEY=your_api_key_here

Key rotation without downtime

Rotating a production key requires a brief overlap period where both the old and new key are valid. Follow this sequence:

  1. Create the new key in the Developer Portal with the same name (add "v2" or today's date to distinguish it)
  2. Update your deployment — set the new key value in your environment variables or secrets manager
  3. Deploy and verify — confirm requests are succeeding with the new key in your application logs
  4. Revoke the old key — only after confirming the new key is working

Never revoke the old key before confirming the new one works. A failed deploy with no fallback means downtime.

CI/CD secrets

Automated pipelines need API keys without human involvement. Store keys in your CI provider's secrets store, not in configuration files.

GitHub Actions

Add your API key as a repository secret:

  1. Go to Settings → Secrets and variables → Actions in your GitHub repository
  2. Click New repository secret
  3. Name it TOWNSHIP_CANADA_API_KEY and paste your CI key value
  4. Click Add secret

Reference it in your workflow file:

# .github/workflows/test.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run integration tests
        env:
          TOWNSHIP_CANADA_API_KEY: ${{ secrets.TOWNSHIP_CANADA_API_KEY }}
        run: npm test

The same pattern applies to other CI platforms — GitLab CI uses project variables, Bitbucket Pipelines uses repository variables, and CircleCI uses environment variables in project settings. The key principle is the same: the secret is stored in the platform, referenced by name in the config file, and never written to disk or logs.

Team key management

On the Business plan, account admins can view all API keys created by team members — including the key name, creator, creation date, and last-used timestamp. This makes it possible to audit which keys are active, identify keys that haven't been used recently, and revoke credentials when a team member leaves.

Individual developers see only their own keys. Admins see keys across the entire team.

If your team uses a shared integration (for example, a company-wide internal tool), create that key under an admin account rather than a personal one. That way the key doesn't become inaccessible if the original creator's account is deactivated.

Security practices

A few habits that prevent the most common problems:

Don't commit keys. The .gitignore pattern above covers most cases. For extra protection, consider a tool like git-secrets that scans commits for credential patterns before they're pushed.

Use separate keys for separate projects. If Project A's key is ever compromised, you revoke that key without touching Project B. It also makes usage monitoring cleaner — each key's activity in the logs maps to exactly one project.

Rotate keys periodically. There's no hard rule on frequency, but a yearly rotation for production keys is a reasonable baseline. After a team member departure, rotate any keys they had access to.

Delete unused keys. Old keys from completed projects or former team members are attack surface with no benefit. If a key hasn't been used in 90 days and you don't recognize its purpose, revoke it.

Treat keys like passwords. Don't paste them into chat messages, emails, or support tickets. If you need to share a key temporarily, do it through a password manager or secrets vault.