Your First Gammal Tech API Project: Setup, Boundaries and Evidence

Understand what this exercise will prove

The deliverable is a small page showing whether the documented SDK methods are available, plus a setup record that explains the connection. It does not save user data, start an AI conversation, send a notification or take a payment. Its narrow scope makes it easier to tell whether a problem belongs to page loading or a later application feature.

You need basic HTML editing, permission to publish to an HTTPS website and control of the account used for your learning project. You also need to understand where your hosting provider expects an HTML file. Keep the practice page separate from a client's live checkout or customer portal. A working readiness page is a useful first milestone, not a security assessment of the whole website.

Prepare the account and project you are entitled to use

If your account is already approved, start at step 2. Follow these actions inside your own account:

1. Open the registration page, create your account once and complete the identity checks shown there. The standard document is a National ID from a country whose citizenship you hold; read the document requirements and limited Egyptian exceptions. Wait for approval before integration; approval can take up to 10 days.
2. Sign in to your account, then open Developer Mode. You will see your project list.
3. Select an existing project, or click Create Project for a new one. Open its page and record the project ID, pid. This is public configuration, not a secret key.
4. In project settings, add the HTTPS domain that will run your website. Register the www hostname and the hostname without it separately if visitors use both.
5. Follow this guide’s integration example or exercise on the registered website. Check one complete task from start to finish and record what happens before adding more features.

Record the project identifier and purpose. The project ID is public; it is not a secret developer API key. Do not invent a secret key, an .env value or an initialization method from examples written for another platform. Use the documented SDK and the actual settings for this project.

For a client engagement, the client should control the client project and account. This personal learning project is not a reason to collect a client's credentials or operate the client's payment arrangements through your own identity.

Register the origin that will actually serve the page

In project settings, register the HTTPS domain used by your exercise. Check the browser address after any redirect: the final hostname is what matters to your setup. The documentation treats www and the domain without it separately and allows up to four registered domains.

Write down your intended origin and the one displayed in the browser. If they differ, resolve the mismatch before debugging the application code. A local file opened directly from your computer is useful for basic HTML practice but does not demonstrate integration on a registered HTTPS domain.

Your page connects to Gammal Tech's hosted API. You are not installing the Gammal Tech platform on your server. The server hosting your page still controls the code visitors receive, so protect its publishing account and review who can change the exercise.

Publish a small SDK readiness page

Save the following as a new HTML page on your authorized practice site. Load the official SDK once, before the script that uses its global object. In an existing application, place the equivalent check in your normal application script instead of inserting duplicate SDK tags. If the site's content security policy restricts inline scripts, use its approved external-script or hash/nonce arrangement; do not weaken the policy for the exercise. The policy must also permit the official SDK source; review required API connections when adding features.

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>SDK readiness practice</title>
<h1>SDK readiness practice</h1>
<p id="status" role="status" aria-live="polite">Checking SDK…</p>
<script src="https://api.gammal.tech/sdk-web.js"></script>
<script>
"use strict";
const status = document.getElementById("status");
const sdk = window.GammalTech;
const required = ["login", "logout", "isLoggedIn", "verify"];
const ready = sdk && required.every(
  name => typeof sdk[name] === "function"
);
status.textContent = ready
  ? "SDK ready. No login attempted."
  : "Unable to prepare this page. Please try again later.";
</script>
</html>

The check asks whether four documented methods exist. The output goes through textContent, and the page does not print exceptions or credentials. A failure produces a neutral message. A successful result means the SDK object and these methods are present, not that an account is authenticated or that a request has passed project access checks.

Debug in the order the browser builds the page

Use browser developer tools only for the information necessary to diagnose the step. Do not publish network exports, tokens or account records in screenshots. Once authentication is introduced, request details may be sensitive. If settings appear inconsistent with the documented behavior, ask support about the specific project configuration without sending session credentials.

Record acceptance results without overclaiming

1. The page is served from the intended HTTPS domain.
2. The official SDK appears once before the dependent script.
3. The page displays the readiness result without launching a login popup.
4. The page contains no secret key and prints no session token.
5. Your record distinguishes SDK readiness from authentication and authorization.

As a local-only comparison, temporarily remove the SDK tag from a duplicate practice file. The neutral failure message should appear. Restore the original file before continuing. This harmless observation teaches dependency failure; it is not a reason to alter a client's production page or registered domains.

Write actual results next to the expected ones. If the page is ready but you have not tested login, record “login not yet tested” rather than “integration fully secure.”

Prepare the evidence for the next lesson

Keep the page source, project purpose, registered origin, final origin and a sanitized readiness screenshot together. Add a simple drawing showing the browser, your website and the hosted API. State who controls publishing access.

The next exercise introduces an explicit login button and a changing session. OWASP's session guidance explains why session credentials deserve protection. Do not add token display as a debugging shortcut. Your progress is the ability to explain the setup and its limits, then add one observable behavior at a time.

Use a fresh exercise page for each later lab. Reuse the project and SDK-loading pattern, rather than accumulating every lesson’s markup and script in one file.

Common questions

Why does this example not contain a secret API key?

The documented Gammal Tech integration does not use a secret developer API key. A public project identifier and a user’s sensitive session credential have different roles; do not treat them as interchangeable.

Does “SDK ready” prove my project is authenticated?

No. It only checks the presence of the SDK and named methods. Login, valid-session behavior and the application’s permission rules require their own separate exercises.