Integrate GeekWala into Your Workflow
Integrate GeekWala into your CI/CD pipeline with our REST API
API Playground
Test API endpoints directly in your browser. Enter your API token for live requests, or try with mock data to explore the API responses.
API Playground
Get all projects for the authenticated user
/api/v1/projectsRequired ability: project:read
No token provided - will show sample response data
curl -X GET "https://geekwala.com/api/v1/projects" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Accept: application/json"Authentication
Secure API access with token-based authentication.
API Access Requirements
- • Pro & Trial: Full API access
- • Free: Read-only tokens (project:read, scan:read)
- • API tokens require authenticated Bearer tokens with abilities
Creating API Tokens
1. Navigate to Automation → API Tokens
2. Click "Create New Token"
3. Provide a descriptive name (e.g., "GitHub Actions", "Jenkins Pipeline")
4. Select token abilities (permissions):
project:readList and view projects
project:writeCreate, update, delete projects
scan:readView scan results
scan:writeTrigger new scans
5. Set expiration: 30 days, 90 days, 1 year, or no expiry
6. Click Create and copy the token immediately (shown only once)
Using API Tokens
Include the token in the Authorization header of all API requests:
curl -H "Authorization: Bearer YOUR_API_TOKEN" \
https://geekwala.com/api/v1/projectsSecurity Best Practices
- • Store tokens as environment variables or CI/CD secrets (never commit to version control)
- • Use minimal abilities required for each integration
- • Set expiration dates for tokens used in temporary workflows
- • Rotate tokens periodically (every 90 days recommended)
API Endpoints
Complete REST API reference for projects and scans.
Base URL
https://geekwala.com/api/v1Pagination
List endpoints support pagination with query parameters:
Offset Pagination (scan lists)
- •
page- Page number (default: 1) - •
per_page- Items per page (default: 50, max: 100)
GET /api/v1/projects/{project}/scans?page=2&per_page=50Cursor Pagination (scan results)
Scan results use cursor-based pagination for efficient large result sets. Use the cursor value from the links.next URL to fetch subsequent pages.
- •
per_page- Items per page (default: 100, max: 500) - •
cursor- Pagination cursor from previous response
GET /api/v1/scans/{id}/results?per_page=100&cursor=eyJpZCI6MTAwfQProject Endpoints
| Method | Endpoint | Ability | Description |
|---|---|---|---|
| GET | /projects | project:read | List all projects |
| GET | /projects/{project} | project:read | Get a specific project |
| POST | /projects | project:write | Create a project |
| PUT | /projects/{project} | project:write | Update a project |
| DELETE | /projects/{project} | project:write | Delete a project |
| POST | /projects/{project}/dependencies | project:write | Add packages to project |
Scan Endpoints
| Method | Endpoint | Ability | Description |
|---|---|---|---|
| GET | /projects/{project}/scans | scan:read | List scans for a project |
| GET | /scans/{id} | scan:read | Get a specific scan |
| GET | /scans/{id}/results | scan:read | Get scan results |
| POST | /vulnerability-scan/run | scan:write | Run a vulnerability scan |
| POST | /projects/{project}/scans | scan:write | Trigger a new scan |
Vulnerability Endpoints
| Method | Endpoint | Ability | Description |
|---|---|---|---|
| GET | /vulnerabilities/{vulnerabilityId} | scan:read | Get full vulnerability details (EPSS, KEV, references) |
| GET | /vulnerabilities/{vulnerabilityId}/header | scan:read | Get lightweight header (summary + aliases) |
| POST | /vulnerabilities/headers | scan:read | Batch fetch headers for multiple vulnerabilities |
Rate Limits
API throttling policies for fair usage.
Pro & Trial
Read: 240 req/min
Write: 30 req/min
Free
Read: 120 req/min
Write: 15 req/min
Rate Limit Headers
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 115
X-RateLimit-Reset: 1609459200Handling 429 Responses
When you exceed the rate limit, the API returns HTTP 429 with a Retry-After header.
async function apiCallWithRetry(url, options, maxRetries = 3) {
for (let i = 0; i < maxRetries; i++) {
const response = await fetch(url, options);
if (response.status !== 429) return response;
const retryAfter = response.headers.get('Retry-After');
await new Promise(resolve =>
setTimeout(resolve, (retryAfter || (i + 1)) * 1000)
);
}
throw new Error('Max retries exceeded');
}CI/CD Integration
Scan your dependencies for vulnerabilities in any CI pipeline. Use our official GitHub Action for the best experience, or the REST API for other platforms.
GitHub Actions (Recommended)
The official GeekWala Security Scan action auto-detects your lockfiles, scans for vulnerabilities enriched with EPSS and CISA KEV data, and posts a summary directly to your workflow run.
name: Security Scan
on: [push, pull_request]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: GeekWala Security Scan
uses: Geekwala/security-scan-action@v1
with:
api-token: ${{ secrets.GEEKWALA_API_TOKEN }}That's it. The action auto-detects your dependency file (lockfiles preferred), scans it, and fails the workflow if critical vulnerabilities are found.
Configuring Security Gates
Customize pass/fail criteria with severity thresholds, EPSS scores, and CISA KEV detection:
- name: GeekWala Security Scan
uses: Geekwala/security-scan-action@v1
with:
api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
# Severity gate: none, low, medium, high, critical
severity-threshold: high
# Fail on actively exploited vulnerabilities (CISA KEV)
fail-on-kev: true
# Fail if any vulnerability has >30% chance of exploitation
epss-threshold: 0.3
# Only fail on vulnerabilities that have a known fix
only-fixed: trueMonorepo Support
For monorepos or projects with dependency files outside the root, specify the path explicitly with file-path:
- name: GeekWala Security Scan
uses: Geekwala/security-scan-action@v1
with:
api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
file-path: packages/api/package-lock.jsonWhen file-path is omitted, the action auto-detects dependency files from the repository root (lockfiles preferred over manifests).
GitHub Code Scanning (SARIF)
Generate a SARIF report to surface vulnerabilities in the GitHub Security tab and as PR annotations:
- name: GeekWala Security Scan
uses: Geekwala/security-scan-action@v1
with:
api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
sarif-file: geekwala-results.sarif
severity-threshold: none # Don't fail here; let Code Scanning handle alerts
- name: Upload SARIF to GitHub
uses: github/codeql-action/upload-sarif@v3
if: always()
with:
sarif_file: geekwala-results.sarifSuppressing Known Vulnerabilities
Create a .geekwala-ignore.yml file in your repository root to suppress accepted risks:
# .geekwala-ignore.yml
ignore:
- id: CVE-2021-23337
reason: "Not exploitable in our usage of lodash"
expires: 2027-01-01 # Auto-unignore after this date
- id: GHSA-xxxx-yyyy
reason: "Accepted risk per security review #42"Ignored vulnerabilities still appear in scan output (marked as suppressed) but don't count toward failure thresholds.
Advanced Configuration
Fine-tune reliability, output formats, and artifact collection:
- name: GeekWala Security Scan
uses: Geekwala/security-scan-action@v1
with:
api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
severity-threshold: high
# Output formats (comma-separated): summary, table, json
output-format: summary,table,json
# Save JSON report for CI artifacts
json-file: scan-results.json
# Reliability settings for slow CI environments
retry-attempts: 3 # Retry transient failures (default: 3)
timeout-seconds: 300 # Scan timeout (default: 300)
- name: Upload scan report
if: always()
uses: actions/upload-artifact@v4
with:
name: security-scan-results
path: scan-results.jsonUsing Scan Outputs
The action provides outputs you can use in subsequent workflow steps:
- name: GeekWala Security Scan
id: scan
uses: Geekwala/security-scan-action@v1
with:
api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
severity-threshold: none # Warn only
- name: Comment on PR
if: steps.scan.outputs.has-vulnerabilities == 'true'
run: |
echo "Found ${{ steps.scan.outputs.vulnerable-packages }} vulnerable packages"
echo "Critical: ${{ steps.scan.outputs.critical-count }}"
echo "High: ${{ steps.scan.outputs.high-count }}"Available outputs: scan-status, total-packages, vulnerable-packages, safe-packages, critical-count, high-count, medium-count, low-count, unknown-count, has-vulnerabilities, ignored-count, sarif-file.
Supported Dependency Files
The action auto-detects these files (lockfiles preferred over manifests):
Quick Scan via API (Any CI System)
For GitLab CI, Jenkins, CircleCI, or any other platform, use the REST API directly:
# Scan package-lock.json and output summary
curl -sf -X POST "https://geekwala.com/api/v1/vulnerability-scan/run" \
-H "Authorization: Bearer $GEEKWALA_API_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"file_name\": \"package-lock.json\", \"content\": $(cat package-lock.json | jq -Rs .)}" \
| jq '.data.summary'
# Output: { "total": 150, "affected": 3, "secure": 147, "totalVulnerabilities": 5 }GitLab CI
Add to your .gitlab-ci.yml. Set GEEKWALA_API_TOKEN in CI/CD Variables:
vulnerability_scan:
stage: test
image: alpine:latest
before_script:
- apk add --no-cache curl jq
script:
- |
RESPONSE=$(curl -sf -X POST "https://geekwala.com/api/v1/vulnerability-scan/run" \
-H "Authorization: Bearer $GEEKWALA_API_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"file_name\": \"package-lock.json\", \"content\": $(cat package-lock.json | jq -Rs .)}")
# Parse results
CRITICAL=$(echo "$RESPONSE" | jq -r '.data.results | map(select(.vulnerabilities[]?.severity == "critical")) | length')
HIGH=$(echo "$RESPONSE" | jq -r '.data.results | map(select(.vulnerabilities[]?.severity == "high")) | length')
echo "Critical: $CRITICAL, High: $HIGH"
# Fail if critical or high found
if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
echo "Vulnerabilities found! Critical: $CRITICAL, High: $HIGH"
exit 1
fi
# Optional: allow failure for non-blocking scans
# allow_failure: trueJenkins Pipeline
Add the token as a Jenkins credential named geekwala-api-token:
pipeline {
agent any
environment {
GEEKWALA_API_TOKEN = credentials('geekwala-api-token')
}
stages {
stage('Vulnerability Scan') {
steps {
script {
def response = sh(
script: '''
curl -sf -X POST "https://geekwala.com/api/v1/vulnerability-scan/run" \
-H "Authorization: Bearer $GEEKWALA_API_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"file_name\": \"package-lock.json\", \"content\": $(cat package-lock.json | jq -Rs .)}"
''',
returnStdout: true
).trim()
def json = readJSON text: response
def critical = json.data.results.count { it.vulnerabilities?.any { v -> v.severity == 'critical' } }
def high = json.data.results.count { it.vulnerabilities?.any { v -> v.severity == 'high' } }
echo "Vulnerabilities - Critical: ${critical}, High: ${high}"
if (critical > 0 || high > 0) {
error "Found ${critical} critical and ${high} high severity vulnerabilities"
}
}
}
}
}
}Best Practices
- • GitHub? Use the official GitHub Action for the best experience
- • Other CI? Use the
vulnerability-scan/runendpoint—it's stateless with no cleanup needed - • Store API tokens as secrets (never commit to version control)
- • Use a dedicated token with only
scan:writeability - • Start with
severity-threshold: noneto assess baseline, then enforce - • Use project-based scans only when you need historical tracking across builds
- • Examples: See ready-to-use workflows in the examples repository (basic, strict, advanced with SARIF)