Skip to main content
The package adds the commands on this page to Artisan. Each one asks for what it needs (Laravel Prompts) and takes options instead in a script. Artisan’s help prints a command’s options, for example the install command’s:
Terminal

Set up

Set the SDK up

Publish the config, write the site’s URL, API key and signing secret to .env, and check the site:
Terminal
When: once, right after composer require, and again whenever you want to point the app at a new key with the key in .env. It publishes config/fetchski-attract.php, asks for the site’s slug, URL, API key and the key’s signing secret (leave it empty for a token-only key), writes FETCHSKI_ATTRACT_SITE, _URL, _API_KEY and _SIGNING_SECRET to .env (and empty ones to .env.example, when the app has one), then runs the check. With no secret, a FETCHSKI_ATTRACT_SIGNING_SECRET left in .env by an earlier key is removed.
In a script
Key in the database
With --database it publishes the config and the attract_api_keys migration, sets FETCHSKI_ATTRACT_SITES_FROM=database, asks before running the migrations, then stores the key. The key never goes to .env (Key in the database).

Store or replace the key

Store the site’s API key and signing secret in the attract_api_keys table, encrypted, or replace the ones stored there:
Terminal
When: with the key in the database, the first time (the database install runs it for you), or to add another site’s key. To swap a stored key for a new one, rotate it. It asks for the site’s URL, the API key, its signing secret and its signing mode, then calls the site with them (the check). The slug comes from the key, so a key for a site already in the table replaces its row, and the old key and secret are gone at once (Replaced the API key for acme…). Before asking anything it checks the table exists and that the SDK reads keys from it, and says what to run when not.
In a script
A queue worker or Octane keeps the client it built until it restarts. After replacing a key, restart the queue workers (and reload Octane):
Terminal

Rotate the key

Swap a stored site’s API key and signing secret for new ones, keeping its row and URL:
Terminal
When: you have a new key for the same site from its CMS (someone left, a secret may have leaked, or it’s simply time) and want the app to use it in place of the old one. It shows which site it’s rotating, then asks for the new API key, its signing secret and its signing mode (the current one is offered first). The new key must be for the same site: a key for another site is refused and nothing changes. The old key and secret are gone from the table at once, then the new key is checked on the site. Before asking anything it checks there’s a stored key to rotate, and says what to run when there isn’t.
One of several sites
In a script
The old key keeps working on the site until you switch it off in its CMS. Restart long-running workers so they pick up the new key:
Terminal

Forget the key

Delete a site’s key from the attract_api_keys table, asking first:
Terminal
When: the app should stop calling the site. Then switch the key off or delete it in the CMS under API Keys too: deleting the row doesn’t stop the key working on the site.
One of several sites
In a script

Work with the methods

List the methods

List every method the SDK offers, with its key, HTTP route and purpose:
Terminal
When: you’re looking for the method that does what you need, or its key for the commands below.
One accessor
As JSON

Call a method

Call one method on the real site and print its answer as JSON:
Terminal
When: you want to see what a method really answers before writing code against it, or to try a call by hand. Arguments are name=value: numbers and true / false are cast, lists and objects are JSON, the rest is taken as written. A write asks first. The full guide, with every argument type and worked examples, is Call any method from the terminal.
Drafts too
A write, without asking

Write an Action

Write an Action for one method, and its test:
Terminal
When: you’re adding a call to your app. The Action is the one place the call lives, and its test fakes the site (Testing). This writes app/Actions/Attract/GetBlog.php, an invokable Action that makes the one call, and its test in tests/Feature/Actions/Attract/ (Pest when the app has Pest). With no method it lets you search them all.
Search for the method
Into a module
In a module the files go to modules/Blog/Actions/Attract/ and its Tests/Feature/Actions/Attract/. With FETCHSKI_ATTRACT_MODULE set, that is where every Action goes, with no option. The module’s folder must exist.

Check a site

Check the setup

Check the config, that the site answers, that the key is accepted, and the clock:
Terminal
When: after setting up or rotating a key, after a deploy, or when calls start failing. The install and store commands run it for you. It prints one line each, ok, warn or fail: the config, the site reachable, the key accepted, and your server’s clock against the site’s (a warning past a minute; signatures allow five). Exits 1 on any failure.
Another site

Sweep every read

Call every read the site offers and report each as ok, refused or broken:
Terminal
When: after upgrading the SDK, or after a change on the site, to confirm everything your key can read still decodes. It exits 1 when one broke.

Publish what you want to change

The config
The attract_api_keys migration
The stubs
The stubs land in stubs/ (the Action and its tests); the Action command uses your copies from then on.