Automated part creation fails due to expired API token in parts management integration

[rohan_architect]

Our nightly automation job that creates parts in Windchill 11.2 M030 via REST API started failing last week with authentication errors. The job has been running successfully for months, but now it consistently fails with 401 Unauthorized responses. The error message indicates the API token has expired.

We generate the API token during our initial setup and store it in our integration configuration. The token was working fine until recently. I checked the token generation code and it looks correct:

String token = apiClient.authenticate(username, password);
config.setApiToken(token);

The automation runs overnight and creates hundreds of parts by calling the Windchill REST API. Now all these part creation requests fail, blocking our nightly data loads from our ERP system. I’m not sure if tokens have a fixed expiry period that I wasn’t aware of, or if there’s a way to implement automatic token refresh logic. We need a solution that doesn’t require manual intervention to renew tokens. Has anyone implemented token refresh handling in their API integrations with Windchill?

I’ll provide a comprehensive solution covering API token refresh logic, automation error handling, and token expiry monitoring.

API Token Refresh Logic Implementation:

The core issue is that your authentication token expires after 24 hours (Windchill’s default), but your automation doesn’t have refresh logic. Here’s a complete implementation:

1. Token Wrapper Class with Expiry Tracking:

Create a token management class that tracks expiry:

public class WindchillToken {
    private String token;
    private long expiryTime;

    public boolean isExpired() {
        return System.currentTimeMillis() >= expiryTime;
    }
}

2. Proactive Token Refresh Strategy:

Implement a refresh mechanism that renews tokens before expiry:

public String getValidToken() {
    if (token.isExpired() || token.expiresWithin(300000)) {
        refreshToken();
    }
    return token.getValue();
}

3. Reactive Token Refresh with Retry Logic:

Implement error handling that detects 401 responses and refreshes the token automatically. This is more efficient than checking before every call:

// Pseudocode - Token refresh with automatic retry:
1. Make API call to create part
2. If response is 401 Unauthorized:
   a. Call refreshToken() to get new token
   b. Update stored token with new value
   c. Retry the original API call with new token
   d. If retry also fails with 401, throw exception
3. If response is other error, handle normally
4. If success, process response and continue

This approach minimizes overhead while ensuring token validity.

4. Token Parsing for JWT Tokens:

If Windchill uses JWT tokens, extract the expiry claim to avoid extra validation calls:

String[] parts = token.split("\\.");
String payload = new String(Base64.decode(parts[1]));
JsonObject claims = JsonParser.parse(payload);
long exp = claims.get("exp").getAsLong() * 1000;

5. Efficient Batch Processing:

For your nightly job that creates hundreds of parts, refresh the token once at the start and implement reactive refresh on failure:

// Pseudocode - Efficient batch processing:
1. At job start: Validate token and refresh if needed
2. Process parts in batches of 50-100
3. After each batch: Check if token expires within next 30 min
4. If expiring soon: Refresh proactively during batch break
5. On any 401 error: Refresh immediately and retry current batch

Automation Error Handling:

Robust error handling ensures your automation recovers from authentication failures:

1. Comprehensive Exception Handling:

Implement specific exception types for different authentication failures:

try {
    response = createPart(partData, token);
} catch (TokenExpiredException e) {
    token = refreshToken();
    response = createPart(partData, token);
} catch (AuthenticationException e) {
    logError("Auth failed after refresh");
    sendAlert();
}

2. Exponential Backoff for Refresh Attempts:

Implement intelligent retry logic with increasing delays:

// Pseudocode - Exponential backoff:
1. Set initial retry delay = 5 seconds
2. Set max retries = 5
3. For each retry attempt:
   a. Wait for current delay duration
   b. Attempt token refresh
   c. If successful, break and continue
   d. If failed, double the delay (5s, 10s, 20s, 40s, 80s)
   e. After max retries, fail job with alert

3. Circuit Breaker Pattern:

Prevent cascading failures if authentication service is down:

• After 3 consecutive token refresh failures, open circuit breaker
• Stop attempting authentication for 5 minutes
• After cooldown period, attempt one test refresh
• If successful, close circuit and resume normal operation
• If failed, extend cooldown and alert administrators

4. Graceful Degradation:

Implement fallback behavior when authentication fails:

• Queue failed part creation requests for retry
• Write failed requests to database or file for later processing
• Continue processing other parts if possible
• After job completion, report failed items for manual review

5. Transaction Management:

Ensure part creation failures don’t leave inconsistent data:

• Wrap each part creation in a transaction
• On 401 error with successful token refresh, rollback and retry entire transaction
• On persistent authentication failure, rollback transaction and log for retry
• Maintain idempotency keys to prevent duplicate part creation on retries

Token Expiry Monitoring:

Proactive monitoring prevents authentication failures from impacting operations:

1. Pre-Job Health Check:

Validate authentication before starting the main automation job:

public boolean validateAuthentication() {
    try {
        testToken = getValidToken();
        testResponse = apiClient.testConnection(testToken);
        return testResponse.isSuccessful();
    } catch (Exception e) {
        return false;
    }
}

Call this health check at job start. If it fails, abort the job immediately and alert administrators rather than discovering failures mid-processing.

2. Token Lifecycle Logging:

Log all token-related events for troubleshooting:

• Token generation: Log timestamp, user, and expiry time
• Token refresh: Log reason (proactive vs reactive), timestamp, success/failure
• Token validation failures: Log error code, message, and context
• Token expiry warnings: Log when token will expire within 1 hour

Example log format:

2025-08-22 02:00:15 - Token generated for user 'api_integration' - Expires: 2025-08-23 02:00:15
2025-08-22 23:45:00 - Proactive token refresh triggered - 15 min before expiry
2025-08-23 08:30:22 - Token refresh failed - Auth service unreachable - Retry 1/5

3. Real-time Monitoring Dashboard:

Create a monitoring dashboard showing:

• Current token status (valid/expired/expiring soon)
• Time until next token expiry
• Token refresh success rate
• Authentication error trends
• API call success/failure rates

4. Alerting Strategy:

Implement multi-level alerts based on severity:

Warning Alerts (email):

• Token expiring within 2 hours with no scheduled refresh
• Single token refresh failure (may be transient)
• Authentication response time degradation

Critical Alerts (email + SMS/Slack):

• 3 consecutive token refresh failures
• Job aborted due to authentication failure
• Token expired during active job execution
• Authentication service unreachable for 10+ minutes

5. Token Expiry Prediction:

Implement predictive monitoring to prevent issues:

• Calculate when current token will expire
• Compare expiry time to scheduled job start times
• Alert if token will expire during a scheduled job
• Automatically refresh token 1 hour before scheduled jobs

6. Metrics Collection:

Track authentication metrics for capacity planning:

• Average token lifetime before refresh
• Token refresh frequency
• Authentication error rate
• Time spent on authentication vs actual API calls
• Impact of authentication delays on job duration

Configuration Best Practices:

1. Externalize Token Configuration:

• Store token refresh settings in configuration file, not code
• Make token expiry buffer configurable (default: 5 minutes before expiry)
• Allow adjustment of retry attempts and backoff multipliers
• Enable/disable proactive vs reactive refresh strategies

2. Secure Token Storage:

• Never store tokens in plain text configuration files
• Use encrypted configuration or secret management service
• Rotate encryption keys periodically
• Implement token encryption at rest

3. Service Account Management:

• Use dedicated service account for API automation
• Grant minimum required permissions for part creation
• Implement regular password rotation for service account
• Monitor service account for unusual activity

Testing Recommendations:

1. Token Expiry Simulation:

• Reduce token lifetime to 5 minutes in test environment
• Run automation job that takes 10+ minutes
• Verify token refresh occurs automatically
• Confirm no part creation failures during refresh

2. Authentication Failure Testing:

• Temporarily disable authentication service
• Verify job implements proper retry logic
• Confirm alerts are triggered appropriately
• Test recovery when service is restored

3. Load Testing:

• Simulate high-volume part creation (1000+ parts)
• Monitor token refresh impact on throughput
• Verify no authentication bottlenecks
• Test concurrent job execution with shared tokens

This comprehensive solution ensures your nightly automation handles token expiry gracefully, recovers from authentication failures automatically, and provides visibility into authentication health through monitoring and alerting.

---

This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

[caro9172]

Windchill API tokens typically have a default expiration period of 24 hours, though this can be configured. Your token is being generated once and stored, but after it expires, your automation has no mechanism to refresh it. You need to implement token refresh logic that detects expiry and requests a new token before making API calls.

Tested this on Windchill 12.1 with our parts management integration — the WindchillToken wrapper class with expiry tracking eliminated all failed automated part creation jobs overnight.

[mia4279]

I recommend implementing a token validation check before each API call or batch of calls. If the token is expired or close to expiry, request a new one. You could also implement a proactive refresh strategy that renews the token every 20 hours, well before the 24-hour expiry, ensuring your nightly job always has a valid token.

[martin_functional]

That makes sense. Should I check the token expiry before every single API call, or is there a more efficient approach? Our job makes thousands of API calls per night to create parts, and I’m concerned about the overhead of constant token validation. Is there a way to check token validity without making an extra API call each time?

[amanda_williams]

You can parse the token to extract its expiry timestamp if it’s a JWT token. Then maintain the expiry time locally and only refresh when approaching expiration. Alternatively, implement error handling that detects 401 responses and automatically refreshes the token and retries the failed request. This is more efficient than checking before every call.

[carmen_codecraft]

Another consideration is implementing exponential backoff for token refresh attempts. If the authentication service is temporarily unavailable, you don’t want your automation to hammer it with refresh requests. Build in retry logic with increasing delays between attempts, and implement a maximum retry limit to prevent infinite loops.

[andrewengineer]

Don’t forget about monitoring and alerting. Your automation should log token refresh events and alert on consecutive refresh failures. This way, you’ll know immediately if there’s an authentication problem rather than discovering failed part loads the next morning. Also consider implementing a health check endpoint that validates token status before the main job runs.