CI/CD Integration

1. Add AIDELLY_API_KEY and AIDELLY_WORKSPACE_ID to your CI secret store. Optionally add AIDELLY_BRAND_ID.
2. Install a tested CLI version in your build, then run a read-only access check.
3. Add a publishing action only after confirming the workspace, platform, and content.

GitHub Actions: read-only check

name: Check Aidelly access
on: workflow_dispatch
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: '24'
      - name: List workspaces
        env:
          AIDELLY_API_KEY: ${{ secrets.AIDELLY_API_KEY }}
          AIDELLY_WORKSPACE_ID: ${{ secrets.AIDELLY_WORKSPACE_ID }}
        run: npx @aidelly/cli workspaces list --json

Pin the package version your team has verified for reproducible builds. A CI runner uses the secret environment rather than interactive auth login.

Scheduled post command

Set AIDELLY_API_KEY, AIDELLY_WORKSPACE_ID, ANNOUNCEMENT, and a future SCHEDULED_AT in your CI environment:

npx @aidelly/cli post create \
  --platform linkedin \
  --text "$ANNOUNCEMENT" \
  --scheduled-at "$SCHEDULED_AT" \
  --json

Use one command per platform. Omitting the scheduled time requests immediate publishing. A successful exit confirms command/request success, not provider delivery; use post get POST_ID to check status.

Retries and idempotency

The CLI generates an idempotency key for each write request. A new CLI invocation creates a new key, so rerunning a whole CI step can create another post. For retries across workflow invocations, call the REST API with a stable source-event Idempotency-Key. Preserve that key for retries of the same event; change it for a new post.

Keep workflow payloads in environment variables or files rather than interpolating untrusted release text directly into shell scripts. Use the command's nonzero exit to fail or alert according to your workflow; avoid treating queue acceptance as publication.

CLI commands · API reference