Platform
The adapters are the visible half. The other half is the platform behind them: a portal where you issue your own keys, see your own connections, set your own configurator, and read where your request at EasternGraphics actually stands. That platform is the reason a new connection is an installation and not a project.
Onboarding
Connections
Four screens, each of them there because the alternative was emailing us to ask.
Four tiles in the order you actually walk them: subscription, key, connection seen, version up to date. A tile that is not done yet tells you the next action instead of leaving you to guess. That is also the answer to the half-finished account: you log in and read what is going on.
Platform, site, version, status and when the connection was last seen, with a warning when a newer release is out. Status and version are read-only on purpose: the status is what gets invoiced, so if you could set your own to ignored the count would be worthless. We would rather say that than pretend. What you do set per connection is the configurator, which is the next card.
Issue a key, paste it into the plugin, and the connection registers itself. Revoke it whenever you want. The raw key exists for exactly one moment and is shown once: we store only a lookup hash and a bcrypt hash, so lost means revoke and issue a new one. Both actions land in an audit trail.
Your pCon.ui gatekeeper comes out of your own licence, so you set it yourself. The portal checks it server-side against EasternGraphics: whether the id exists at all, whether your domain is already on their whitelist, and whether your instance ends in a shopping cart or in a quote request. You read the real status instead of asking us for it.
Underneath it sits the configurator profile: interface language, manufacturer data language, VAT country, scene background, length unit, whether the price shows. Your account holds the default and every shop may differ, because these describe the embedding and not the licence. A consumer shop and a B2B shop arrive at different answers. You set it in the portal, not in the plugin.
The adapters are not on wordpress.org or packagist, so they have their own update channel. That channel is also the collection lever, which is exactly why it is worth being precise about what it does and does not do.
If a subscription lapses the plugin tells the administrator and keeps working. It stops receiving updates. There is nothing in the code that can disable a shop you already paid to have built.
Platform, version, package, checksum and publication date cannot change. Deleting is refused and so is un-publishing. Correcting something means a new version number, so the build you installed last month is still the build you installed last month.
The adapter checks the package hash before anything is unpacked. WordPress gets its update in the normal updates screen, Magento gets a private Composer repository, Odoo gets the same JSON check. Each platform in the way it expects.
Your agency is going to install this and then own it. These are the things they will want to know before they say yes, and they can all be checked.
Catalogue, bridge and updates each have a written contract with a version number that says what an adapter may assume. Responses carry anX-Pcon-Contract header, and the shapes are pinned by tests, so a breaking change cannot ship quietly.
A new adapter is written against the contract rather than by reading an existing plugin. That is why a second shop platform or a second ERP is an adapter rather than a second product.
The pCon licence forbids crawling, so the recursive catalogue walk has hard limits on article count and depth. Raising them takes a reason. That keeps your licence out of trouble, not just ours.
A list of absences is more useful than a list of features, because this is where you find out whether it fits how you work.
The status and the version of a connection are ours to set, because that is the invoice. If you think a connection is counted wrongly, tell us and we fix it on our side. Everything that describes the embedding is yours.
The connection to pCon's own services stays behind the platform. You set your gatekeeper, which is yours, and nothing below it.
We create your user and hand over the password. An invitation flow only makes sense once customers can sign themselves up, and that depends on EasternGraphics as much as on us.
The portal is where your keys, connections and configurator live. If you do not have an account yet, the intake is the way in.